Skip to main content

Access control

DecisionHub separates identity, organization membership, solution access, roles, policies, and environment permissions. A user sees an action only when all applicable layers permit it.

Understand the layers​

Organization membership​

The member must belong to the organization and be active. Organization-level permissions control members, teams, roles, policies, solutions, environments, deployments, execution history, retention, statistics, settings, and SSO.

Solution access​

The member must also have access to the selected solution. Solution permissions control the Hub, HubItem editing/versioning/deletion, tests, connectors, and API keys. Access to one solution does not grant access to another.

Environment qualification​

Runtime permissions can be environment-specific. A tester may run and debug in Test but not Production. Connector configuration, Global Variable values, and API keys are also associated with environments.

Plan and resource state​

A role cannot grant a feature excluded from the organization plan. Inactive organizations, solutions, environments, or memberships can also disable actions.

Roles​

A role is a named permission bundle. System roles provide common organization and solution responsibilities. Custom roles let administrators select permissions from the available tree.

Create role names based on responsibility:

  • Decision Author – view and edit HubItems, create versions, run Development tests;
  • Test Analyst – view assets, run and debug in Test, manage saved tests;
  • Release Approver – view deployment evidence and approve requests;
  • Production Operator – execute approved deployments and inspect production history;
  • Integration Administrator – manage/test connectors and API keys.

The exact permissions shown in the role editor are authoritative for your installation and subscription.

Policies​

A policy assigns a role to a member or team, optionally for a solution. Effective access is additive across applicable policies.

Example:

Team: Lending Authors
Role: Decision Author
Solution: Lending
Member: release.manager@example.com
Role: Release Approver
Organization scope

Removing a user from a team removes access derived from that team but does not remove a direct policy. When investigating unexpected access, review direct assignments and every team the member belongs to.

Invite a member​

In Organization → Members:

  1. Enter the email address.
  2. Choose an organization role.
  3. Optionally choose a solution and solution role.
  4. Optionally add teams.
  5. Send the invitation.

Pending invitations do not provide active access until accepted. If organization SSO is required, use an address in the configured corporate domain; external identity-provider assignment alone does not create DecisionHub membership.

Least-privilege examples​

Author who cannot release​

Grant Hub read/edit, version creation, and Development testing. Do not grant deployment approval/execution, production debug, connector secret management, or API-key creation.

Tester who cannot change logic​

Grant Hub view, Testing Zone, saved tests, and appropriate environment debug. Do not grant HubItem editing or deployment execution.

Machine integration​

Create a solution/environment API key with the narrowest resource permissions, a practical expiration, and appropriate rate limits. Do not create a shared human account or reuse an OData reporting key.

Separation of duties​

For governed releases, separate:

Author → creates version and deployment request
Approver → reviews evidence and approves
Operator → executes approved deployment

Smaller teams may combine roles, but the policy should be deliberate and auditable.

Debug and sensitive data​

Debug permission can expose request payloads, intermediate values, rule matches, and connector responses. Grant it only to members permitted to see that data, especially in Production. Retention policy is not a replacement for access control.

Troubleshooting access​

When a control is missing or disabled, check:

  1. active organization selection and membership;
  2. active solution selection and access;
  3. direct and team policies;
  4. relevant environment permission;
  5. subscription feature availability;
  6. resource status and deployment state.

Changing a role can affect many members. Prefer adding a targeted policy when only one user or solution needs different access.

SSO​

SAML SSO is an organization authentication setting and requires the applicable plan and update permission. It remains invitation-based. See Organization SAML SSO.