Fill out the relevant information. Everything in the fields can
be edited after user creation.
The Login ID field should contain an email address for internal users.
If you edit the Login ID field, the user is in pending status until they
sign in again with their new credentials.
Change permission group level
If you select a permission group with edit permissions for
All Environments, you will see that selection here. To change this at permission group level,
select None for All Environments on the Permissions page.
After you make this change, you can select one environment or more
for the user to have access to.
Click Add. The new user appears in the list of users,
and an email invitation is automatically sent.
For internal users, the status remains as 'Pending' until they accept
the invitation to join SOAR and create a password.
The password link is valid for 3 days. If the user hasn't accepted the
invitation by then, the administrator can click Send Invitation on the
User Management page to resend the invitation.
For SAML users the status remains as "Pending" until the first time they login.
They can sign in directly to the platform without the need to use the invitation
email.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-03-09 UTC."],[[["This guide explains how to add a new user to the Google Security Operations SOAR standalone platform, involving navigating to the User Management section, inputting user details like email and selecting the appropriate SAML provider if necessary."],["New users, upon being added, receive an email invitation that internal users must accept to set their password, whereas SAML users can log in directly without the need to go through the email invite."],["User access is controlled through permission groups, which define visible and editable modules, SOC roles, which allow for case or action assignments to roles rather than individuals, and environments or environment groups, which segment data for different business units."],["Users can be assigned to multiple permission groups, SOC roles, and environments, with the platform combining permissions from each group and deciding a landing page based on a defined hierarchy upon login."],["Restricting actions for users requires that the specific action be selected as restricted in every permission group assigned to that user, otherwise they will not be restricted."]]],[]]