Permission Groups
Overview
Permission groups are reusable bundles of capabilities that you compose into roles. Each group lists the resources (test cases, folders, automation objects, business objects, systems under test, schedules, scripts, database validation rulesets, users, roles, and so on) together with the activities — read, write, execute, delete, change owner — that members of the group are allowed to perform on each resource.
Use this page to see every permission group defined in your tenant, find a group by name or description, and open one for inspection or editing. From here you also start the creation of a new permission group.
A permission group on its own grants nothing. It only takes effect once it has been linked to a role, the role has been linked to a user, and (where relevant) the link has been scoped to a project scope. Permission groups therefore act as building blocks: keep each one focused on a single capability ("Display test cases and results", "Execute test cases", and similar) and then assemble roles from several groups rather than building one monolithic group per role.
Not all activities are valid for every resource. For example, the licence resource only supports read and write; users have no execute activity; only schedules support change owner; business objects and database validation rulesets support read, write, and delete but not execute. The system enforces these combinations when you save a permission group and rejects invalid pairs.
Tasks
How to create a new permission group
- Click Create New in the toolbar.
- Fill in the name, description, and the resource-and-activity entries on the form that opens.
- Save the group. After saving you can link it from one or more roles to make it effective.
The Create New button is disabled if you do not have the Permission Group: Write permission.
How to export the list
- Click Export in the toolbar.
- Choose Export to Excel to download the visible rows as an Excel workbook, or open the menu to pick Export to PDF instead.
The export is disabled when the list is empty.
Field reference
| Field | Description |
|---|---|
| Name | Human-readable identifier of the permission group. Click the value to open the group's detail page. |
| Description | Free-text description that explains the capability the group represents. Long values are truncated in the list; hover to see the full text. |
| Created By | Username of the person who created the group. |
| Created At | When the group was created, shown as a relative time (for example, "3 days ago"). Hover to see the exact timestamp. |
Tips & edge cases
- Permission groups are unscoped on their own. A group only lists what activities are allowed on what resources. Scoping to a project happens later, when the group is linked from a role.
- You cannot delete a permission group that is still linked to a role. Remove the group from every role first; the system blocks the delete otherwise.
- A group can contain the same resource only once meaningfully. The list of activities for a resource is stored as a set; duplicates may appear in the editor but produce no extra effect.
- Invalid resource-activity combinations are rejected on save. For example, you cannot add execute to the licence resource, or to a business object or database validation ruleset. The form surfaces the offending pair so you can fix it.
- Execution of business objects and database validation rulesets is gated elsewhere. These two resources only carry read, write, and delete. Running anything that uses them is controlled by the execute activity on test cases and automation objects instead.
- Changes are tracked. Every create, edit, and delete on a permission group is recorded in the audit log, including who made the change and when.
Related features
Prerequisites & permissions
About permissions. Int4 Suite controls what you can see and do through roles and permission groups assigned to your user. Each role grants permissions on a specific resource (for example, Test Case, Automation Object, System Under Test) at one of four levels: Read, Write, Delete, or Execute. Some permissions are further narrowed by project scope, so you may have access to one part of the system but not another.
If a button is disabled or a list comes back empty, missing permissions are the most likely cause. Ask an administrator to review your role assignments, or check IAM → Users if you have the User: Read permission.
To use this page you need:
- Permission Group: Read to see the list and open any group.
- Permission Group: Write to enable the Create New button and to save changes from the detail page.
- Permission Group: Delete to remove a group from the detail page.
These activities apply globally — permission groups themselves are not scoped to a project scope.