Roles
Roles define groups of users who share responsibilities in a Protrak application. Administrators use roles to control who can see pages and widgets, create records, work in lifecycle states, perform promote actions, run reports, and participate in configured business rules.
Use roles when access or user experience should follow a responsibility model, such as Administrator, Manager, Reviewer, Field User, Supplier, Customer, or Process Owner.
What roles control
| Area | How roles are used |
|---|---|
| Type access | Control which roles can create instances of a type or use the type in reports. |
| Lifecycle permissions | Control what users can view, edit, link, unlink, delete, or promote in each lifecycle state. |
| Promote actions | Restrict transitions such as Submit, Approve, Reject, Complete, or Reopen to the roles responsible for them. |
| Design Studio visibility | Show page templates, forms, containers, and widgets only to selected roles. |
| Rules and access policies | Evaluate the current user's roles when deciding whether something is visible, required, or accessible. |
| Programs and notifications | Find users by role, assign or remove roles, and send notifications to role-based recipients. |
Common configuration flow
- Define the roles that match the application's responsibility model.
- Assign users to one or more roles.
- Configure type-level access for create and report permissions.
- Configure lifecycle state permissions and promote-action access by role.
- Configure Design Studio templates, forms, and widgets for role-specific experiences.
- Use rules or access policies when access depends on the user's role and the current record context.
- Validate the application with users in each role.
Guidance
- Name roles after responsibilities, not individual people.
- Keep role sets simple; use lifecycle permissions, rules, or access policies for context-specific behavior.
- Validate both allowed and restricted experiences after changing role assignments.
- Review templates, widgets, lifecycle actions, rules, access policies, notifications, and programs before renaming or removing a role.