# Permissions and Resource Limits > Choose role permissions, resource limits, and conditions from the organisation IAM catalogue. 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 management** > **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. ## Infuse IoT API Access The Infuse-IoT Cloud API currently authorises IoT permissions across the whole organisation. A role or direct grant that limits an IoT permission to specific devices, boards, networks, or applications does not yet allow calls to the Infuse-IoT Cloud API. A request that relies only on a resource-limited IoT grant is denied. Until resource-level support is available for Infuse IoT, grant IoT permissions organisation-wide to identities that call the Infuse-IoT Cloud API. Use a separate, purpose-specific service account and the narrowest IoT role, such as **IoT Viewer** or **Device Operator**, to keep that access small. If an identity has both a resource-limited grant and an organisation-wide grant for the same permission, the organisation-wide grant applies. ## 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. ```http GET /iam/permissions ``` Supported filters include module, namespace, feature, preview status, role scope, and search text. Each permission includes: - `id` - `identifier` - `module` - `feature` - `action` - `name` - `description` - `isPreview` ## Resource Types Some permissions can be scoped to resource types. The IAM API exposes the resource-type catalogue: ```http GET /iam/resource-types ``` Supported filters include module, type, organisation-scope support, hierarchical-scope support, and search text. Each resource type includes: - `id` - `identifier` - `module` - `type` - `description` - 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.