Once you have created application roles and assigned end users to them, you can use those roles to configure what each end user sees and does inside your application. There are two places to do this:
- in a data view record filter, so that each end user only sees the records that belong to their role (show records by role), or
- in a module condition, so that a module behaves differently depending on the roles the current end user holds (branch a module by role).
The examples in this article use an application with two roles, Sales and CS, and an Accounts database that both teams share.
Show records by role in a data view
You keep the role name in your data, in an ordinary text field. When an end user opens the data view, BRYTER compares that field against the roles the end user holds and returns only the matching records. There is no dedicated field type for this.
To configure it:
- Add a text field to your database that holds the role name for each record. In the example below, the field is called Team, and each account holds either Sales or CS.
- Open your data view and click the FILTER tab.
- Under Show records where, select your role field, then choose the operator user has matching role. There is no value to enter, because the roles come from the end user who is viewing the data view.
- Publish your application. Each end user now only sees the records whose role field matches one of their roles.
Note that the field value is compared literally to the role name, including capitalization, e.g., sales does not match a role called Sales. If a filter appears to have no effect, check this first.
You can combine the role condition with other conditions using the All and Any grouping in the Rule Builder, e.g., show records where Status is Open and the end user has a matching role.
Example: The Accounts database has a Team field that holds either Sales or CS. An end user on the sales team opens the data view and sees the accounts where Team is Sales. An end user in customer success opens the same data view and sees the CS accounts instead. One data view serves both teams, and nobody maintains a separate copy.
Show a data view action only to end users with a matching role
Data view actions are the buttons on each record, configured in the ACTIONS tab. You can restrict them with the same role condition:
- Click the ACTIONS tab and select your action.
- Enable Show conditionally.
- Under This action is visible where, select your role field and choose the operator user has matching role.
This works in the same way as the record filter, comparing a field on the record against the roles of the end user who is viewing the data view. It is therefore most useful when the action needs to check a different field than your record filter. If both the record filter and the action check Team, the action condition has no additional effect, because end users only see matching records in the first place.
Note that the condition is evaluated when the action runs, not only when the button is displayed.
Branch a module by role
Modules provide the roles of the current end user as a built-in value. User ▸ Roles is the list of role names that the end user holds. You find it in the value picker under the User built-ins, next to User ▸ Email and User ▸ Full name.
User ▸ Roles behaves like any other list of text, so you can use it wherever a text list is valid. Conditions are the most useful place. Because the value is a list, the condition needs a quantifier in addition to an operator.
To configure it:
- Add a condition to the transition out of your node.
- Set the value to User ▸ Roles, the quantifier to Any and the operator to =, then enter the role name.
- Point Go to at the step that this role should reach.
- Repeat for each role that needs its own path.
Example: The Accounts playbook module branches on the role of the end user. One condition reads Any of User ▸ Roles = Sales and points to Final to Sales. A second condition does the same for CS and points to Final to CS. An end user on the sales team runs the module and lands on Final to Sales, while an end user in customer success lands on Final to CS. The branch labels in the flow, any = Sales and any = CS, show which role each path belongs to.
The same pattern also works for action conditions and conditional values, so you can run an approval action, display a section or preset a value for one team and not for another.
Quick reference
| Where you use it | What to configure |
|---|---|
| Data view record filter | user has matching role on your role field |
| Data view action visibility | Show conditionally, then user has matching role on your role field |
| Module condition | User ▸ Roles, Any, =, your role name |
Note on role names and environments
- Roles are assigned per environment, and an end user without an assignment holds no role at all. Check that the end users you expect hold the role in the environment where the application actually runs.
- End users without a matching role do not see anything that is role restricted. In a data view, they see no role-filtered records. In a module, a roles condition treats their roles as an empty list.
- Matching is based on the role name in both places, so keep the names in your data and conditions consistent with the roles you have defined.
- Renaming or deleting a role does not update the places where the role is used. BRYTER warns you when you rename or delete a role. After either change, update your data view fields and module conditions accordingly.
- A role field holds one value per record, so each record grants access to a single role. If a record needs to be visible to several roles, add another field and condition, or add one record per role.