Changing User Experience Permissions

User experience permissions are used within trellispark to determine if a particular element is visible to users, and whether it can be modified by the user. These can be changed based on the state of the record (e.g. “draft” or “approved”); the user’s assigned roles; or any custom rule defined by the business. This allows for precise control of when and how data can be viewed, changed, or deleted.

User experience permissions are set at three levels: form, tab, and field; with each controlling a different aspect of the user experience:

• Form permissions are used to determine whether records of the concept can be saved or deleted by the current user. By default, Delete is suppressed for Portals and Applications and Save/Delete are allowed for Concepts.
• Tab permissions are used to determine visibility of a tab within a specific form based on the user’s assigned roles or the state of the form. The data in some tabs may not be useful or appropriate for all users to see, while still being a required feature of the overall form. By default, all Tabs are visible.
• Field permissions are used to determine if a field within a displayed tab is visible and can be modified by a user. By default, all fields are visible and modifiable.

Example Video

How to set the precedence of a permission

The default rules are applied if no explicit user experience permissions have been set for the form, tab, or field.

As soon as an explicit permission has been created, the user must match one of the defined permissions or be denied access to the object that it controls. So, for a form, failing to match an explicit permission suppresses Save/Delete, and for Tabs/Fields the control is hidden.

The Priority of the permission determines how important this rule is within the hierarchy; base permissions should be set with a priority of 0, with more important permissions having higher numbers. Permissions can go as high as 100 to allow fine tuning of which users can save and delete this form.

Permissions are matched from highest to lowest priority with the first match determining the user’s access. Permissions matching is commonly set based on the state of the record and the roles that the user has, although the use of TSQL allows for custom selection criteria defined by business rules.

If no Roles or States are selected in the permission’s check lists, the assumption is that all roles or all states will be matched by this permission. Users may have multiple roles that will have different access requirements to a record; in the case that users are covered under multiple access permissions, the permission with the highest priority will overwrite all below to ensure that the user has access to everything that they need to be able to view and change.

If there are complex business rules to applied, then these can be accommodated using a custom T-SQL stored procedure. The following parameters will be required:

• SessionGUID
• UserGUID
• CurrentInstanceGUID
• TargetInstanceGUID

These are used to verify that the user has logged in to a valid session and identify which Record the permissions are being checked for.

The T-SQL stored procedure will return a simple yes “Y” or no “N”.

To learn how to create custom stored procedures, see here

Form Permissions

Form permissions are set on the form’s Permissions tab on a Form Definition and determine whether Records of the concept can be saved or deleted by the current user. Form permissions are used only by Concepts and Portals.

The most basic permissions set by the form permissions is whether this form can be deleted or saved in its current condition or by the user viewing it. Each form permission will include a Save and a Delete field that will determine if the user should have access to the corresponding buttons; this may require a TSQL stored procedure to calculate. This means that the data should have a certain amount of innate integrity; only people who have appropriate access can make any lasting changes to the data, and the data cannot be deleted while in certain states or by people who do not have the appropriate clearance. For example, this means that a Contract could not be deleted from the Active state in the user experience, and the Delete button would not even be visible.

Some permissions may be more complex and only be activated based on the data stored within the form. These permissions can use a TSQL stored procedure in the Save TSQL or Delete TSQL fields that can be triggered whenever the form is saved or deleted. When the Save or Delete button are pressed, the provided TSQL will be run and check if the form permissions will allow the form to be saved or deleted based on the current state of the form. This can be done by T-SQL stored procedures within the database with the following parameters:

• SessionGUID
• UserGUID
• CurrentInstanceGUID
• TargetInstanceGUID

Tab Permissions

Tab permissions are created from the Permissions tab within a Tab Definition form. Tab permissions are used to control the visibility of tabs to keep the user interface as clear as possible.

By default, tab permissions are assumed to be visible until a new tab permission is created. Once a specified tab permission exists this assumption switches to assume that the tab will be invisible unless the user’s role or form’s state specifically allow it to be seen. This is used to simplify the process of locking down a tab to only the specific circumstances under which it should be seen.

Field Permissions

Field permissions are created on the Permissions tab within a Field Definition. They are used to define whether or not a specified field within the form should be visible, required, or editable by the user, assuming that the user has been granted permission to view and edit this form. It allows for a more fine grained degree of control over what parts of a field a user may need to see, but should not be allowed to change.

Field permissions will be created from the Permissions tab in the Field Definition:

Each field permission will require a Priority in case there are multiple conflicting permissions; the permission with the lowest numbered priority will be applied. Whether this permission will apply to a specific Platform (Mobile, Web, or Desktop application), Role of the user, or State of the original form, these will need to be indicated using the appropriate fields.

A series of single select options will be used to indicate if the field is Visible, Modifiable, or Required within the original form, which can each be set to Yes, No, or use a provided TSQL stored procedure . The Allow Row Click field will determine if this field can be selected within a table (?)

Different styling can be applied to the field based on the results of this field permission check, using the same Label Style, Description Style, and Control Style fields that are used within the Field Definition directly.