Permissions and Resource Limits
Permissions control specific actions on Infuse resources. Roles bundle permissions into access patterns that can be assigned directly to users or service accounts, or inherited through groups.
When granting access, start with the narrowest role that allows the workflow to succeed. Broaden access only when the caller genuinely needs it.
Review Role Permissions
Use Access > Roles to inspect the permissions included in an organisation role.
The Permissions view shows:
- the human-readable permission name,
- the stable permission identifier,
- whether the permission applies organisation-wide or to specific resources,
- the resource type and resource ID or pattern when access is limited.
Search by name or identifier and filter the list by product module.
Choose Permissions for a Role
When creating or editing an organisation role, the permission catalogue can be searched and filtered by module. Use All, Selected, and Available to review the draft, and Select visible when the filtered set is the exact access pattern you need.
The Portal only offers permissions that can be used by organisation roles. Permission definitions themselves are maintained by Infuse; role administrators choose which available permissions an organisation role includes.
Limit Access to Resources
Some permissions support resource-specific access. Select Limit access beside a compatible permission, then choose the resource type and resource from the picker.
Use organisation-wide access only when the principal needs the permission across the whole organisation. A resource limit is narrower: the permission grants access only when both the resource type and resource identifier match.
Advanced mode accepts one exact resource ID or a pattern using * and ?. Use it when a resource is not available in the picker or when a carefully reviewed group of resource IDs should match. Resource patterns never grant a permission for a different resource type or organisation.
Not every permission can be limited. If Limit access is not available, that permission applies across the organisation boundary when granted.
Conditions
Roles can include time-based conditions. All conditions must match before the role grants access, and times are evaluated in UTC.
Editing a role can immediately change access for every direct assignee and group member who inherits it. Review the warning shown by the Portal before saving changes that remove permissions, remove supported principal types, or change a restriction to organisation-wide access.
Permission Catalogue
The IAM API exposes the same organisation-safe permissions catalogue for integrations and tooling that need to inspect available permissions.
GET /iam/permissions
Supported filters include module, namespace, feature, preview status, role scope, and search text.
Each permission includes:
ididentifiermodulefeatureactionnamedescriptionisPreview
Resource Types
Some permissions can be scoped to resource types. The IAM API exposes the resource-type catalogue:
GET /iam/resource-types
Supported filters include module, type, organisation-scope support, hierarchical-scope support, and search text.
Each resource type includes:
ididentifiermoduletypedescription- whether organisation scope is supported
- whether hierarchical scopes are supported
Direct Grants
Roles should be the default way to grant access. Direct permission grants are for narrow exceptions where one user or service account needs a specific permission rather than a reusable role.
Authorised administrators can add and revoke direct grants from a member's Access view or a service account's Access tab. Choose an explicit organisation-wide or resource-specific scope and, when appropriate, a start or expiry time. Use direct grants sparingly because role and group assignments are easier to review and maintain.