Administration and Governance
  • 23 Nov 2022
  • 8 Minutes to read
  • Contributors

Administration and Governance


Article summary

Learn how to manage various user roles and set restrictions within Tulip.

Organizing Roles Within Tulip

Tulip has several ways to manage roles between users and direct certain functionalities to specific accounts on an Instance or a particular application.

Designate User Roles

When determining who has what level of authority in applications, it’s important to understand what the different levels of access are. A Tulip instance has an unlimited number of users who can access it. With this capability, you want to restrict users to have only the highest level of access needed to complete their tasks.

There are three main categories of access in Tulip:

User

Users can access both Tulip and the Tulip Player. Capabilities include building and managing apps as well as running them in the Player. They include roles such as Account Owners, Administrators, Application Engineers, Tulip Table Supervisors, Connector Supervisors, and Station Supervisors.

Viewer

Viewers can only view assets in Tulip. This means they have access to Tulip apps through the App Editor, but cannot run them through the Player. Their roles include Viewers, Station Operators, and Application Approvers.

Operators

Operators can only access the Tulip Player. They strictly run apps through the Tulip Player and cannot access the App Editor or other pages regarding machine and connector information. Their roles include Viewers with Player Access and Operators.

Further Reading

For an extensive explanation of each role and their capabilities in regards to various parts of the Tulip platform, see Adding Users and Managing User Roles.

Set App Roles and Restrictions

You can also set restrictions and abilities for users on individual applications. With Permissions and Approvals, you can set the specific app privileges and reviewing abilities designated to individual users. To access the Permissions and Approvals settings, select an app from the Apps page and click on the respective tabs located below the app description.

Permissions and Approvals Tabs.png

Permissions

With Permissions, you can restrict editing privileges per app. This ensures that users only have editing permissions for the apps that pertain to the lines they work on. Otherwise, they’d have access to a variety of apps unnecessary for their work. Limiting permissions ensures quality control and access based on a need-to-have basis.

There are four types of permissions:

  • Can view - Users can view apps and their assets, for roles such as quality assurance
  • Can edit - Users can edit apps in the App Editor, for roles such as engineers and supervisors
  • Can publish - Users can edit apps in the App Editor and publish them, for roles such as Subject Matter Experts and
  • Owner - Users can do everything and delegate permissions to users, for roles such as Administrators

For information on how to set permissions, see How To Change Editing Permissions on Individual Apps.

Approvals

Approvals assign who is responsible for reviewing and approving apps before publication. Regulated industries may require multiple parties to review an app to ensure it meets requirements and standards for production.

By default there are three types of approvals in Tulip:

Approvals Default.png

You can set up more approvals as needed by going to the Approvals tab, located in Workspace Settings for Enterprise customers and in Account Settings for all other customers, after clicking on your user icon.

For information on how to set up approvals, see How To Set Up Approvals for Your Apps.

In-App Access Control

As another means of controlling access, you can use Fields in Tables and Step level Triggers and App Level Triggers as well. In a table, you can set up fields that designate user roles to associated Users and with those in place, set Triggers that fire only if a user has a particular role.

For example, if you want only supervisors to have the ability to complete an app, create a trigger that only Completes the app if a user has the role of supervisor.

For more information on updating User fields, see How To Update Fields on Individual Tulip Users and Operators From Apps.

Version Control

When using applications in production, there will likely be changes you’ll make to apps that are currently in use. With Published Versions, you can save all information and data from a previous version while working on a new one. This ensures that production won’t be impacted even as an app is revised.

There are two types of app versions:

Development Version

A Development Version of an app is still being worked on by app builders in the App Editor. To run this version, use Developer Mode. Developer Mode allows you to run an app without affecting the version in production. You can skip between Steps, view the Variables used on each step, and test functionality with all assets such as Widgets, buttons, and more.

Published Version

A Published Version of an app is able to run in the Tulip Player and an official release of an application. You can have multiple published versions as you edit an app to update standards and functionalities. Because numerous versions exist, you can easily go back to a previous published version if you need to reload it. For example if you update a function in an app and later determine that the previous version was more efficient, you can easily go back to the previous one.

Further Reading


Did you find what you were looking for?

You can also head to community.tulip.co to post your question or see if others have faced a similar question!


Was this article helpful?