Users

Overview

The Users screen lists everyone who can sign in to Int4 Suite and is where you decide what each person may do. A user record holds the person's email address and name, whether the account is active, and the roles assigned to it. Roles are the only way a user receives permissions: a user without a role can sign in but cannot open any screen that needs a permission.

Int4 Suite does not keep passwords. People sign in through your organization's identity provider, and the first successful sign-in creates their user record automatically — without any role. An administrator then assigns one or more roles here. If you want someone to be ready to work the moment they first sign in, create their user record in advance: Int4 Suite links it to the person's sign-in account by email address at their first sign-in.

Each role assignment can carry a validity period, so you can grant access for the duration of a project or a test phase without having to remember to remove it afterwards.

Open the screen from IAM → Users.

Tasks

How to create a user in advance

1. Click Create New in the toolbar.
2. On Create User, enter the person's Email. Use exactly the address the person signs in with; it is what links the record to their sign-in account.
3. Optionally enter First Name and Last Name. They are replaced by the names from the identity provider at the first sign-in.
4. Click Save. The user's page opens.
5. Assign roles as described in "How to assign or change roles". Roles cannot be added while the user is being created — the Roles card says Create the user first, then assign roles.

Creating a user here does not create a sign-in account. The person still needs an account with the same email address in your identity provider. Until they sign in for the first time, the record waits unused.

How to assign or change roles

1. Open the user from the list.
2. Click Edit.
3. In the Roles card, click Add role. A new row appears.
4. Pick the role in the Role column.
5. Optionally set Valid From and Valid To. Leave both empty for an assignment without time limit.
6. To take a role away, use the delete control at the end of its row. The row is marked for removal and can be restored until you save.
7. Click Save. The assignments you see are saved as a whole and replace the previous set. Cancel puts the saved assignments back.

If the card shows You do not have permission to manage role assignments., you can open the user but not change roles.

How to deactivate or reactivate a user

1. Open the user from the list.
2. Click Deactivate.
3. In the Deactivate User dialog, confirm with Deactivate. The account is marked Inactive and the person's sessions at the identity provider are ended.
4. To give access back, open the user and click Activate.

Users cannot be deleted. Deactivation keeps the record, so ownership and change history stay readable.

Important: a deactivated account becomes active again when the person next signs in successfully through the identity provider. To keep someone out reliably, also remove all of their roles here and ask your identity-provider administrator to disable the person's sign-in account.

How to export the list

1. Optionally narrow the list with the search box.
2. Click the export button at the right of the toolbar and choose Export to Excel or Export to PDF.

The file contains the columns you see, in their order, and the rows loaded so far. Scroll further down first if you need more rows.

Field reference

List columns

The list shows every user. Type part of an email address, first name or last name into Search users... to narrow it; Clear filters resets the search. More rows load as you scroll, and the count above the list shows the total number of matches. The search is kept in the page address, so you can bookmark or share a filtered view.

Column	Description
Email	The address the person signs in with. Click it, or anywhere on the row, to open the user.
First Name	Given name, as last received from the identity provider (or as entered when the user was created in advance).
Last Name	Family name, from the same source.
Active	Whether the account is active.
Roles	How many roles are assigned, including assignments outside their validity period.

User page

Field	Description
Email	Sign-in address. Unique, regardless of upper or lower case. Can only be entered when the user is created; afterwards it is kept in sync with the identity provider.
First Name	Given name. Read-only after creation; refreshed from the identity provider at each sign-in.
Last Name	Family name. Same behaviour as the first name.
Status	Active or Inactive.
Role	An assigned role. Each role can be assigned to a user only once.
Valid From	First day on which the role applies. Empty means "from now on".
Valid To	Last day on which the role applies (inclusive). Empty means "without end".
Date Joined	When the user record was created — at the first sign-in, or when an administrator created it in advance. Shown in the Admin section.
Last Login	The last recorded sign-in. Sign-ins through the identity provider are currently not recorded here, so this field is usually empty.

Tips & edge cases

• New users start without access. Someone who signs in for the first time gets a user record but no role. They see "You don't have access to this page" until you assign a role.
• Validity dates are whole days. A role applies from the start of Valid From to the end of Valid To, judged by the server's date. Outside that window the assignment stays listed but grants nothing. Make sure the end date is not before the start date — such an assignment never applies.
• Names are owned by the identity provider. Changes you would like to make to a person's name or email address must be made in the identity provider; Int4 Suite picks them up at the next sign-in.
• Assign each role once. To change the dates of an assignment, edit the existing row instead of adding the role a second time; a second row for the same role cannot be saved.
• Changes reach other people's screens with a short delay. Permissions are checked on the server immediately, but a person who is already signed in may need to reload the page (or wait a few minutes) before newly allowed buttons become active.
• SAP BTP installations. Where Int4 Suite runs on SAP BTP, people who hold the application's administrator authorization in SAP BTP automatically receive the Administrator role whenever they use the application; removing that role here does not last.
• No bulk assignment. Roles are assigned one user at a time. To see everyone who holds a role, open the role on the Roles screen.

Related features

• Roles — the bundles of permissions you assign to users.
• Permission groups — the building blocks of roles.
• Project scopes — partition permissions by project or business area.
• Profile — where each person can see their own access.

Prerequisites & permissions

About permissions. What you can see and do is decided by the roles assigned to your user. Each role bundles permission groups, and each permission group allows activities — Read, Write, Delete, Execute and, for schedules, Change owner — on a kind of record (for example Test Case, Automation Object, System Under Test). A role grants its groups per project scope, so you may be allowed to change records in one project but only view, or not see, those of another.

If a button is disabled, a page says you don't have access, or a list comes back empty, missing permissions are the most likely cause — or, for whole product areas, the installed licence. You can review your own access under Profile → My access; an administrator can change your roles under IAM → Users.

To work with this screen you need:

• User: Read — to open the list and a user's page. Without it you are taken to an access-denied page.
• User: Write — to create users and to open a user for editing.
• Role: Read — to see a user's role assignments.
• Role: Write — to add, change or remove role assignments.
• User: Delete — to deactivate a user. Reactivating requires User: Write; the Activate button is currently enabled only for people who also hold User: Delete.

Users are not tagged with project scopes, so a grant in any project scope is enough. In the shipped roles, these permissions come with the Administrator role (permission group "Manage users and role assignments").

Was this page helpful?Send a quick note to the documentation team.

0 / 2000 characters