Overview
Business Activity Monitoring (BAM) uses a role-based access control model to govern what users can see and do within the module. Every Turbo360 account has a designated Account Owner who has full access to the platform. That user can add any number of users to Business Activity Monitoring and assign them system-defined or user-defined roles.
Roles and permissions apply to both the Custom Logging (Push Model) and Data Queries (Pull Model) types. The same role configuration UI is used for both models. Some permissions and access policy features are specific to one model and are noted where they apply.
Business value
Fine-grained role management reduces security risk by ensuring users only have access to the Business Processes and features relevant to their responsibilities. Teams can separate concerns between monitoring specialists, developers, and administrators without granting broad platform-level access.
How it works
BAM roles operate on two dimensions: the role type (system-defined or user-defined) and the scope at which the role is assigned (entire module, Business Process group, or individual Business Process).
When a user is assigned a role at a given scope, they can only perform the actions permitted by that role within that scope. Users with narrower scope assignments cannot access Business Processes outside their assigned scope, even if they hold a role in the same module.
System-defined roles
Business Activity Monitoring includes three built-in roles:
| Role | Access level |
|---|---|
| Owner | Full access to the module, including user and role management. Only the Account Owner and module Owners can manage users and roles. |
| Contributor | Manage access to everything at the scope at which the role is assigned. |
| Reader | Read access to everything at the scope at which the role is assigned. |
Scope
The scope of a role determines the level at which its permissions apply. In Business Activity Monitoring, a role can be scoped to any of the following levels:
- Entire module — the role applies to all Business Process groups and Business Processes in the module.
- Business Process group — the role applies to all Business Processes within the group.
- Business Process — the role applies to a single Business Process only.
The Scope column in the user list indicates whether each user's access comes from an account-level role or a direct assignment on a specific Business Process.
Specify custom permissions
When adding a user with a system-defined role, you can optionally restrict their access to specific Business Process groups and Business Processes using the Specify custom permissions dialog. This lets you grant a role (such as Reader or Contributor) but limit it to a subset of the BAM tree rather than the entire module.
The dialog lists all available Business Process groups and their child Business Processes across both the Custom Logging (Push Model) and Data Queries (Pull Model) types. Each group and process can be individually enabled or disabled using the Revoke / Grant access toggle. A Role dropdown next to each entry lets you assign a different role at that specific scope.
Key behaviors:
- Enabling a Business Process group automatically includes all child Business Processes within it, unless individual processes are toggled off separately.
- The role assigned at a group level applies to all its child Business Processes unless overridden at the process level.
- Both Custom Logging and Data Queries Business Process groups appear in the same dialog — you can grant access to processes from either or both types in a single operation.
- If no properties have been assigned for a user, a Configure link at the bottom of the dialog lets you set a global property access policy (Push Model only).
User-defined roles
Account Owners and module Owners can create any number of custom roles. A user-defined role specifies exactly which permissions apply within a Business Process context.
Each user-defined role includes two permission sets:
- Management permissions — controls whether the role holder can manage users and their role assignments within the module.
- Feature permissions — controls access to specific BAM features. The role creator can grant either view-only or manage access per feature group.
The following feature permission groups are available when creating or editing a role:
| Feature group | Permissions available | Model |
|---|---|---|
| Business process group | View business process group, Manage business process group | Both |
| Business process | View business process, Manage business process | Both |
| Dashboard | View dashboard, Manage dashboard | Both |
| Monitoring | View monitor settings, Manage monitor settings, View Query monitor settings, Manage Query monitor settings, View Duration monitor settings, Manage Duration monitor settings, View Exception monitor settings, Manage Exception monitor settings | Both (Duration and Exception monitoring permissions apply to Push Model only) |
| Transactions | View transactions, Manage transactions | Both |
| Tracking | View saved queries, Manage saved queries, Reprocessing, Manage payload, Manage transaction instance | Both (Reprocessing and Manage payload apply to Push Model only) |
| Global properties | View global properties, Manage global properties | Push Model only |
| Escalation policy | Manage escalation policy | Both |
Permission groups marked Push Model only are visible in the role configuration UI for all deployments but only take effect in Custom Logging (Push Model) environments. In Data Queries (Pull Model) environments, these permissions have no impact even if assigned.
Steps
Use the following steps to add and delete user-defined roles. Navigate to the Roles tab within the User management section of Business Activity Monitoring to get started.
Add a role
Adding a role lets you define a custom permission set for users who need access that differs from the three system-defined roles.
- Click Add role in the Roles tab.
- Enter a name and an optional description for the role.
- Under Specify account permissions, toggle Manage notification channels if required.
- Under Specify management permissions, enable Manage users or Manage escalation policy as needed.
- Under Specify feature permissions, toggle the required view and manage permissions for each feature group.
- Click Save.
Delete a role
Deleting a role requires you to reassign all users currently holding that role before the deletion is confirmed. This prevents users from losing module access.
- Locate the role in the Roles tab.
- Click Delete role in the Actions column.
- Select a replacement role to assign to all users currently holding the role being deleted.
- Confirm the deletion.
System vs user-defined roles
System-defined roles (Owner, Contributor, Reader) apply broadly at whatever scope they are assigned. Operations that modify the Business Process itself — such as editing or deleting a Business Process, managing global properties (Push Model), updating service principal details (Pull Model), and managing storage configuration (Push Model) — require at minimum a Contributor role.
User-defined roles allow more granular control. For example, a team lead who manages the full BAM configuration but should not manage users can be assigned a Contributor role at the module level without the user management permission. A contractor who works only on a development Business Process can be given a user-defined role scoped to that Business Process only.
Access policy for global properties
The global property access policy is available in the Custom Logging (Push Model) type only. It does not apply to Data Queries (Pull Model) environments, which do not use global properties.
The Account Owner can restrict a user's visibility of transaction instances based on global property values. When a global property access policy is configured, the user only sees transaction instances that contain the global property values assigned to them.
To configure global property access, click Configure when granting permissions to a user. A single global property can be configured with multiple allowed values.
Export user details with permissions
To export account user details and their permission assignments as a CSV file, navigate to User management in Business Activity Monitoring and click the Export icon. The export includes permission levels for each user across all scopes in the account.
Troubleshooting
-
A user can access Business Processes they should not be able to see.
Cause: The user has a direct module-level role that overrides more restrictive Business Process-level assignments.
Fix: Review the user's direct role assignment in the User management section. If module-level access is too broad, replace it with specified access scoped to the correct Business Processes using the Specify custom permissions dialog. -
Deleting a role fails or the Delete role option is unavailable.
Cause: The role has one or more users assigned to it and no replacement role has been selected.
Fix: When prompted during deletion, choose a valid replacement role to reassign all affected users before confirming. -
A user-defined role is missing a feature group in the Add role panel.
Cause: Feature permission groups are tied to module features; unavailable groups may reflect a feature not enabled for the account.
Fix: Verify that the feature is available in your Turbo360 plan. Contact support if a feature group is expected but absent. -
Global property access policy is configured but the user still sees all transaction instances.
Cause: The global property filter applies to Push Model (Custom Logging) environments only, and only when transaction instances contain the configured global property. Instances without the property are unaffected. This policy has no effect in Pull Model (Data Queries) environments.
Fix: Confirm your BAM deployment type. If using the Push Model, verify that the relevant Business Processes are configured to capture the global property as a tracking field. -
Exported CSV does not include some users.
Cause: The export reflects the current state of the account. Users who were removed before the export was generated will not appear.
Fix: Check the export timestamp and reconcile against any recent user removal actions.