Access Control List
The Access Control List (ACL) is the central place where administrators define what actions users and groups can perform on entities across B2Win Suite. It uses a hierarchical inheritance model, allowing you to set system-wide defaults and override them at specific levels when needed.
Permission Hierarchy
By default, every entity inherits permissions from its parent. When you set permissions at the system level, those rules automatically apply to all workspaces, workflows, companies, and DB connections — unless they have been individually configured to override them.
How to View and Edit ACL
Navigate to System Settings → Access Control List.
The ACL list shows all entities that have custom (non-inherited) permissions configured. Entities still using their inherited defaults do not appear in this list.
To edit permissions for a specific entity, find it in the list and open its permission configuration. To configure permissions directly on an object (such as a workspace or DB connection), use the Permissions button on that object's management page.
Permission Structure
Each permission entry defines access rules for a specific subject (a user, group, or "All Users"). For each subject, you specify:
| Setting | Description |
|---|---|
| Subject | The user, user group, or "All Users" the rule applies to |
| Allow | Specific actions this subject is permitted to perform |
| Deny | Specific actions this subject is explicitly blocked from, even if an Allow rule exists |
Deny rules always override Allow rules. If a user is both allowed by a group rule and denied by a specific user rule, the deny takes precedence.
Common Permission Types
The available permission types depend on the entity. Common permissions across entity types include:
| Permission | Applies To | Description |
|---|---|---|
WORKFLOW_READ | Workflow | View the workflow and its configuration |
WORKFLOW_MOD | Workflow | Open and modify the workflow in the builder |
WORKFLOW_CHGPERM | Workflow | Change the workflow's own permissions |
WORKFLOW_EXECUTE | Workflow | Manually execute or trigger the workflow |
WORKFLOW_EXPORT | Workflow | Export the workflow |
WORKFLOW_DEPLOY | Workflow | Deploy or undeploy the workflow to production |
WORKFLOW_IMPORT | Workflow | Import a workflow |
WORKSPACE_READ | Workspace | View the workspace and its contents |
WORKSPACE_MOD | Workspace | Modify workspace settings |
WORKSPACE_CHGPERM | Workspace | Change the workspace's own permissions |
MENU_MOD | Workspace | Modify menu configuration |
DB_READ | DB Connection | View and use a database connection |
DB_MOD | DB Connection | Modify a database connection |
DB_SYNC | DB Connection | Synchronize/sync a database connection |
DB_CHGPERM | DB Connection | Change a database connection's permissions |
System-Level Permissions
System-level permissions define the defaults inherited by all new entities. They represent the baseline that applies unless a specific entity overrides it.
Recommended approach:
- Set conservative system-level defaults (for example, restrict editing to Developers only).
- Override at the workspace level for departments that need different access.
- Override at the workflow level for particularly sensitive or restricted workflows.
Workflow-Level vs. System-Level
Workflow-level permissions (configured in Workflow Settings → Permissions) work alongside ACL rules. For a user to successfully perform an action:
- The system-level ACL must permit the action (or the entity has a custom override that permits it), and
- The workflow-level permission must permit the action
Both checks must pass. Either one can independently block an action.
Inheritance Override
To give a specific entity its own permission rules (breaking inheritance):
- Navigate to the entity's management page (for example, a workspace in Configuration → Workspaces, or a workflow in the builder).
- Click Permissions.
- Uncheck Inherit to enable custom permissions.
- Configure the custom rules as needed.
From that point, changes to the parent-level permissions no longer affect this entity.
To revert to inherited behavior, check Inherit again — the entity's custom rules are discarded and it resumes inheriting from its parent.
Notes
- A user who is an Administrator bypasses most permission checks and always has full access.
- When a permission subject (user or group) is deleted, references to it in ACL rules are automatically cleaned up.
- For group-based permissions, all members of the group inherit the group's rules. Adding or removing a user from a group immediately changes their effective permissions everywhere the group is referenced.