Difference between revisions of "Users"
imported>Aeric |
imported>Aeric |
||
(35 intermediate revisions by the same user not shown) | |||
Line 5: | Line 5: | ||
==About Users== | ==About Users== | ||
A User has a login identity, password, email address, and other descriptive attributes. That information is stored in a User record. You create such a record when you add a user. | A User has a login identity, password, email address, and other descriptive attributes. That information is stored in a User record. You create such a record when you add a user. | ||
When a User is added, a record is added to the database. Tasks and activities associated with that user are then tracked in the [[Audit Log]]. | |||
The assignments made in the User record determine the user's privileges: | The assignments made in the User record determine the user's privileges: | ||
Line 11: | Line 13: | ||
:* [[Application Access]] settings determine which applications the user can run, and which Roles they can assume in those applications. | :* [[Application Access]] settings determine which applications the user can run, and which Roles they can assume in those applications. | ||
:* A user's [[Role]] determines their ability to view and modify data for individual application [[Object]]s. If a user has multiple Roles available, they choose which one is in force at any given time. | :* A user's [[Role]] determines their ability to view and modify data for individual application [[Object]]s. If a user has multiple Roles available, they choose which one is in force at any given time. | ||
::''Learn more:'' [[User, Team and Role Guidelines]] | |||
:''Learn more:'' [[User, Team and Role Guidelines]] | |||
==Working with Users== | ==Working with Users== | ||
{{PermissionRef|User Management|add new users in the platform}} | {{PermissionRef|User Management|add new users in the platform}} | ||
:''Learn More: [[ | :''Learn More: [[Role Permissions]]'' | ||
===Standard User=== | |||
AgileApps has a number of internal users for different purposes. These internal users with their unique value IDs are known as Standard Users. The value of ID’s is 1, 2, 3, 4, 5, and 7. The details of these Standard users can be seen from SQL browser. These standard users can be viewed but cannot be modified as they have details which are configured as per customer Tenant or AgileApps application. Any modification to these Standard Users can cause unexpected behavior. | |||
The below Value IDs with Username is not allowed by any type of user under any Tenant. This is applicable for all the Tenants in the AgileApps application. | |||
::{| border="1" cellpadding="5" cellspacing="1" | |||
! <br>Value ID !! <br>username !! <br> Description | |||
|- | |||
| 1 || align="center"| Self_service_portal || Used for customer support login team ID. | |||
|- | |||
| 2 || align="center"| Web_site || Used for website users ID. | |||
|- | |||
| 3 || align="center"| System || Used in some auto operations like business schedule rule, schedule report, and so on. | |||
|- | |||
| 4 || align="center"| Open_ownership || Used in record ownership field if a record is created without any assigned user. | |||
|- | |||
| 5 || align="center"| customersupport@relationals.com || Used for managing tenants. Any tenant capability changes are done by this user. | |||
|- | |||
| 7 || align="center"| guestuser || Used for a case record owner created by a guest user (Only if case creation by a guest user is enabled. | |||
|} | |||
===Add a User=== | ===Add a User=== | ||
Line 25: | Line 47: | ||
#* Note that some fields are [[Required Field |required]]. | #* Note that some fields are [[Required Field |required]]. | ||
#* See this information about selecting a [[User Name]]. | #* See this information about selecting a [[User Name]]. | ||
#Click '''[Save]''' | #Click '''[Save]'''<br>An email is sent to the user, giving them their initial password. | ||
# In the [[Application Access]] page, specify the applications the user can access and the roles they can assume in those applications. | # In the [[Application Access]] page, specify the applications the user can access and the roles they can assume in those applications. | ||
Line 40: | Line 62: | ||
{{Note|The ability to edit users is subject to the [[Permissions Hierarchy]] restrictions.}} | {{Note|The ability to edit users is subject to the [[Permissions Hierarchy]] restrictions.}} | ||
===Delete a User=== | |||
{{Note|Delete a user functionality is available on the Cloud for AgileApps version 10.10 and above.}} | |||
To delete an existing user: | |||
#Click '''[[File:GearIcon.png]] > Administration > Access Management > Users'''. | |||
#Select the user you want to delete. | |||
#From the top menu options, select '''Delete'''. In the Delete Confirmation dialog box, click OK. The system finds the references of this user in AgileApps modules and displays the reference-message if any. If no references are found, the application deletes the user from the system. Any reference message displayed by the system, you need to resolve manually in order to delete the user. For more information, see User References. Also, during deletion, the access profile attached to the deleted user is detached. A new access profile "Deleted User Access Profile" is assigned to the deleted user. This profile does not have any capability enabled and is not visible to the end user. | |||
{{Note|You will see the Delete button only if User Management is set to '''Yes''' in the User and Ownership Controls section of Access Profiles. For more information, see [[Access Profiles]] and [[Permissions Hierarchy]]. However, if you still do not see the '''Delete''' button, contact your application support team or your system administrator if applicable.}} | |||
:Some values that continue to remain as is even after a user is deleted are as follows: | |||
::*User information like username, email, phone, and so on present in audit logs, debug logs and relational logs. | |||
::*User data that contains static text (ones entered manually by a user) in any field such as Description, Subject, any of the custom fields. | |||
::*User information that is currently saved as part of the activity-history for a record. | |||
====Activity History==== | |||
Activity History contains the following user data: | |||
:*User full name | |||
:*User email address | |||
:*User username | |||
The purpose of retaining this information in the Activity History is to keep a record of the user activity. This data continues to remain in the Activity History till this content is manually removed from the system. | |||
In order to remove the user data from Activity History, you have to raise a request with the Application Support team and provide the following information: | |||
:1. User email address. For example, John.Peter@abc.com | |||
:2. User username. For example, John.Peter | |||
:3. Primary ID | |||
{{Note| Only the user email address and username is masked upon manual removal of data from the activity history. Any static text related to user full name; for example, First Name or Last Name continues to remain as is and is not masked.}} | |||
On removal of the user data from the activity history as part of the GDPR compliance, the username henceforth is masked. For example, John.Peter would be masked as Unknown User (Jo Pe). Also, the email address would be masked based on a pre-decided format. For example, John.Peter@abc.com becomes JoXX.PeXXX@abc.com. As a user, you can select the format for masking your email address. | |||
====Support for Business Rules==== | |||
You can create user business rules to perform actions prior to deleting a user or post deleting a user. | |||
:1. Click [[File:GearIcon.png]] > Customization > System Objects. | |||
:2. Select '''User Business Rules'''. | |||
:3. In the '''On Record''' drop-down list, you can select from the following options and click '''New Rule''': | |||
:::*Pre-Delete - If you select this option, you can choose either '''Update Record''' or '''Invoke Method''' in the '''Actions to Perform''' field. Use this option, to complete any pending activity or update, associated with the user you are going to delete. | |||
:::*Post-Delete - If you select this option, you can select only '''Invoke Method''' in the '''Actions to Perform''' field. Use this option, to use custom java classes to remove any personal information of the user stored in the custom field or in any other storage. | |||
====User References==== | |||
There are five attributes of a user that are searched for by the application to find the user-references into the various modules in AgileApps before deleting a user. They are as follows: | |||
:*User ID - generated by system | |||
:*Username - chosen by the user while creating or registering | |||
:*Email - email address of the user | |||
:*Federation ID - if applicable | |||
:*CCA Federation ID - if applicable | |||
Some examples of AgileApps modules for which the system expects a user-reference are as follows: | |||
:*Business Rules (any conditions, expressions or actions may contain the user-references like email address of the user, user_id, username, and so on) | |||
:*Macros (any conditions, expressions or actions may contain the user-references like email address of the user, user_id, username, and so on) | |||
:*Reports / Views / Dashboards (any formula-field expressions, filters or visibility-control may contain the user-references like email address of the user, user_id, username, and so on) | |||
:*SLAs | |||
:*Sites | |||
:*Scheduled Reports | |||
:*Custom Access Criteria expressions | |||
:*Web Forms | |||
:*Task Delegation | |||
:*Proxy Login | |||
{{Note| Some aspects of user deletion to be noted are as follows: | |||
:*The dependency messages displayed have internationalization support and it shows the associated objects or application names, if applicable, along with the name of the dependency-item. | |||
:*User with administrator rights created during the tenant creation or registration are not deleted from AgileApps as this user has some dependencies in the inbuilt Reports and Dashboards that are used by the internal system. | |||
:*Any dependencies should be resolved by the user (/admin) manually by means of the dependency-message that are displayed on the screen. Once resolved, only then the selected user is deleted from AgileApps. At times, a user reference may be present in some artifact that is deleted and may reside in the Global Recycle Bin. Hence, check the recycle bin as well for resolving any user dependencies before you try and delete the user. For example, a user reference may be present in a view. So you should delete this view permanently. For more information, see the section on Deleting a view in [[List Views]]. | |||
:*If any SSO users are deleted from the system and the same user accesses AgileApps again through Identity Provider, a new user is created with the same information passed in SAML response. | |||
:*If any LDAP users are deleted from the system but still exist in LDAP and then at a later point in time accesses or logs-in with same credentials into AgileApps, a new user is created with the same information present in the LDAP server. | |||
:*If any Portal user is deleted, all contact information related to that user is also deleted by the application. | |||
}} | |||
===Reset a User Password=== | ===Reset a User Password=== | ||
Line 55: | Line 141: | ||
===Deactivate a User=== | ===Deactivate a User=== | ||
When a user leaves your organization, you manage the change by Deactivating that user. That action frees up a License that can be applied to a new user, while preserving the former user's history of record ownership, activities, tasks, and so on. (The delete operation is not allowed, for reason. | When a user leaves your organization, you manage the change by Deactivating that user. That action frees up a License that can be applied to a new user, while preserving the former user's history of record ownership, activities, tasks, and so on. (The delete operation is not allowed, for that reason.) | ||
{{Tip|In a large organization, it is good practice to create a team to hold deactivated users.}} | {{Tip|In a large organization, it is good practice to create a team to hold deactivated users.}} | ||
To deactivate a user: | '''To deactivate a user:''' | ||
#Remove the user from all but one team - see [[Remove Team Members]] | #Remove the user from all but one team - see [[Remove Team Members]] | ||
#Deactivate the User | #Deactivate the User | ||
Line 65: | Line 151: | ||
#*Open the user record, and deselect (uncheck) the Active checkbox. (Verify that the Active checkbox is not checked). | #*Open the user record, and deselect (uncheck) the Active checkbox. (Verify that the Active checkbox is not checked). | ||
This user is now deactivated, and the License is now free to assign to another user. | This user is now deactivated. The deactivated user no longer appears in User lookups, and the License is now free to assign to another user. | ||
:'''Note:'''<br>To change the number of licenses in your subscription, modify your [[Subscription Summary|Subscription Plan]]. | |||
'' | '''To make the username available for someone else:''' | ||
:* Change the username to something no one else will ever use. | |||
:: For example: NOSUCHPERSION_1. | |||
:: The original username is now available for someone else to use. | |||
==User Settings== | ==User Settings== | ||
{{:User Settings}} | {{:User Settings}} | ||
==For Developers== | |||
When using the [[REST API]] to Add a User, the ''password'' is optional, and not required. Password policies are implicit and are applied automatically when a new user record is created. | When using the [[REST API]] to Add a User, the ''password'' is optional, and not required. Password policies are implicit and are applied automatically when a new user record is created. | ||
:''Learn more: [[Record_Resource#Add_a_Record|Add a User (Record)]]'' | :''Learn more: [[Record_Resource#Add_a_Record|Add a User (Record)]]'' |
Latest revision as of 08:22, 13 May 2020
> Administration > Access Management > Users
A user is a person who can access the platform, run applications, and view or modify data, as specified by their privileges.
1 About Users
A User has a login identity, password, email address, and other descriptive attributes. That information is stored in a User record. You create such a record when you add a user.
When a User is added, a record is added to the database. Tasks and activities associated with that user are then tracked in the Audit Log.
The assignments made in the User record determine the user's privileges:
- The Team a user belongs to determines which data is shared with other users.
- A user's Access Profile specifies global privileges for viewing and modifying data that is available to them. It also specifies administrative privileges.
- Application Access settings determine which applications the user can run, and which Roles they can assume in those applications.
- A user's Role determines their ability to view and modify data for individual application Objects. If a user has multiple Roles available, they choose which one is in force at any given time.
- Learn more: User, Team and Role Guidelines
2 Working with Users
Users that have the User Management permission can add new users in the platform.
- Learn More: Role Permissions
2.1 Standard User
AgileApps has a number of internal users for different purposes. These internal users with their unique value IDs are known as Standard Users. The value of ID’s is 1, 2, 3, 4, 5, and 7. The details of these Standard users can be seen from SQL browser. These standard users can be viewed but cannot be modified as they have details which are configured as per customer Tenant or AgileApps application. Any modification to these Standard Users can cause unexpected behavior.
The below Value IDs with Username is not allowed by any type of user under any Tenant. This is applicable for all the Tenants in the AgileApps application.
Value ID
username
Description1 Self_service_portal Used for customer support login team ID. 2 Web_site Used for website users ID. 3 System Used in some auto operations like business schedule rule, schedule report, and so on. 4 Open_ownership Used in record ownership field if a record is created without any assigned user. 5 customersupport@relationals.com Used for managing tenants. Any tenant capability changes are done by this user. 7 guestuser Used for a case record owner created by a guest user (Only if case creation by a guest user is enabled.
2.2 Add a User
To add new users:
- Click > Administration > Access Management > Users
- Click the [New User] button
- Fill in the User Settings.
- Click [Save]
An email is sent to the user, giving them their initial password. - In the Application Access page, specify the applications the user can access and the roles they can assume in those applications.
2.3 Edit a User
To Edit User Information:
- Click > Administration > Access Management > Users.
The default view displays all Active Users. You can select another type of user, if required, from the Views icon. - Click the Edit link next to the name of the user you want to edit.
- Modify the User Settings. Note that some fields are required.
- Click [Save]
- In the Application Access page, make changes to the list of applications the user can access and the roles they can assume in those applications.
- Optionally, choose one of the following actions:
Note: The ability to edit users is subject to the Permissions Hierarchy restrictions.
2.4 Delete a User
To delete an existing user:
- Click > Administration > Access Management > Users.
- Select the user you want to delete.
- From the top menu options, select Delete. In the Delete Confirmation dialog box, click OK. The system finds the references of this user in AgileApps modules and displays the reference-message if any. If no references are found, the application deletes the user from the system. Any reference message displayed by the system, you need to resolve manually in order to delete the user. For more information, see User References. Also, during deletion, the access profile attached to the deleted user is detached. A new access profile "Deleted User Access Profile" is assigned to the deleted user. This profile does not have any capability enabled and is not visible to the end user.
Note: You will see the Delete button only if User Management is set to Yes in the User and Ownership Controls section of Access Profiles. For more information, see Access Profiles and Permissions Hierarchy. However, if you still do not see the Delete button, contact your application support team or your system administrator if applicable.
- Some values that continue to remain as is even after a user is deleted are as follows:
- User information like username, email, phone, and so on present in audit logs, debug logs and relational logs.
- User data that contains static text (ones entered manually by a user) in any field such as Description, Subject, any of the custom fields.
- User information that is currently saved as part of the activity-history for a record.
2.4.1 Activity History
Activity History contains the following user data:
- User full name
- User email address
- User username
The purpose of retaining this information in the Activity History is to keep a record of the user activity. This data continues to remain in the Activity History till this content is manually removed from the system. In order to remove the user data from Activity History, you have to raise a request with the Application Support team and provide the following information:
- 1. User email address. For example, John.Peter@abc.com
- 2. User username. For example, John.Peter
- 3. Primary ID
On removal of the user data from the activity history as part of the GDPR compliance, the username henceforth is masked. For example, John.Peter would be masked as Unknown User (Jo Pe). Also, the email address would be masked based on a pre-decided format. For example, John.Peter@abc.com becomes JoXX.PeXXX@abc.com. As a user, you can select the format for masking your email address.
2.4.2 Support for Business Rules
You can create user business rules to perform actions prior to deleting a user or post deleting a user.
- 1. Click > Customization > System Objects.
- 2. Select User Business Rules.
- 3. In the On Record drop-down list, you can select from the following options and click New Rule:
- Pre-Delete - If you select this option, you can choose either Update Record or Invoke Method in the Actions to Perform field. Use this option, to complete any pending activity or update, associated with the user you are going to delete.
- Post-Delete - If you select this option, you can select only Invoke Method in the Actions to Perform field. Use this option, to use custom java classes to remove any personal information of the user stored in the custom field or in any other storage.
2.4.3 User References
There are five attributes of a user that are searched for by the application to find the user-references into the various modules in AgileApps before deleting a user. They are as follows:
- User ID - generated by system
- Username - chosen by the user while creating or registering
- Email - email address of the user
- Federation ID - if applicable
- CCA Federation ID - if applicable
Some examples of AgileApps modules for which the system expects a user-reference are as follows:
- Business Rules (any conditions, expressions or actions may contain the user-references like email address of the user, user_id, username, and so on)
- Macros (any conditions, expressions or actions may contain the user-references like email address of the user, user_id, username, and so on)
- Reports / Views / Dashboards (any formula-field expressions, filters or visibility-control may contain the user-references like email address of the user, user_id, username, and so on)
- SLAs
- Sites
- Scheduled Reports
- Custom Access Criteria expressions
- Web Forms
- Task Delegation
- Proxy Login
Note: Some aspects of user deletion to be noted are as follows:
- The dependency messages displayed have internationalization support and it shows the associated objects or application names, if applicable, along with the name of the dependency-item.
- User with administrator rights created during the tenant creation or registration are not deleted from AgileApps as this user has some dependencies in the inbuilt Reports and Dashboards that are used by the internal system.
- Any dependencies should be resolved by the user (/admin) manually by means of the dependency-message that are displayed on the screen. Once resolved, only then the selected user is deleted from AgileApps. At times, a user reference may be present in some artifact that is deleted and may reside in the Global Recycle Bin. Hence, check the recycle bin as well for resolving any user dependencies before you try and delete the user. For example, a user reference may be present in a view. So you should delete this view permanently. For more information, see the section on Deleting a view in List Views.
- If any SSO users are deleted from the system and the same user accesses AgileApps again through Identity Provider, a new user is created with the same information passed in SAML response.
- If any LDAP users are deleted from the system but still exist in LDAP and then at a later point in time accesses or logs-in with same credentials into AgileApps, a new user is created with the same information present in the LDAP server.
- If any Portal user is deleted, all contact information related to that user is also deleted by the application.
2.5 Reset a User Password
- Click > Administration > Access Management > Users
- Click the [Reset Password] button
- Use the Lookup to Select a User
- Click [Save].
The user's password is reset and a temporary password is emailed to the user's email address.
Note:
- The user is required to change the Password and verify the Security Question at Login.
- Users who are recognized via the LDAP Configuration are not included in the list of users whose password can be reset. Such changes must be made in the LDAP directory.
- When session management capability is enabled, all existing user sessions will be logged out when the password is reset or changed.
2.6 Customer Support Login
A Service Provider's Customer support often needs to login to a tenant, so they can help with its configuration. The Customer Support Login lets them login as the admin user in the specified tenancy, to do that.
Users that have the Customer Support Login Permission permission can Login by Proxy to a Tenant
To Login by Proxy to a Tenant:
- Open the Tenants object
- Navigate to the Tenant of interest
- In the Quick Links section, click the Customer Support Login link to login as this user
- This Login by Proxy is tracked in the Audit Log, and is visible to the user
- When the investigation is complete, click the Switch Back link to exit the Proxy Login and revert to your last login state
2.7 Proxy Login as this User
As an administrator responsible for a number of Users, it is often convenient to diagnose user issues by logging in via proxy. With this login, you gain full access to all actions available to the user. (Each action performed during a Proxy Login is audited and logged.)
Users that have the Proxy Login Access permission can Login as another user to troubleshoot problems that may arise in a user's account
When a Proxy Login is initiated, a dialog box opens to remind the user that a record of these actions will be created. The user can opt to continue or cancel the action.
- To execute a proxy login
- Click > Administration > Access Management > Users
- Select a user
If your role has the capability to do a proxy login, the [Proxy Login] button is visible. - Click the [Proxy Login] button.
A confirmation dialog appears. - Click [OK]
- If this is a first-time login, you may need to answer a Security Question
- The name of the user will appear on the screen, in place of your username
- Perform any necessary troubleshooting activities
Note: You can only login-by-proxy as a member of your team or one of its subteams, as specified by the Permissions Hierarchy restrictions.
- To close a proxy login session
- Click the down arrow next to your name at the top of the window.
- A drop down appears with additional options.
- Learn more: Using the Agent Portal#User Options
- Click the Switch Back link that appears above the Logout option.
- Confirm that your login name appears on the screen, which indicates that you have successfully closed the Proxy Login session.
2.8 Manage Proxy Login Permissions
Grant Users the ability to Login as selected Users or a group of users in a Team.
Users that have the Proxy Login Configuration permission can enable Proxy Login for users
To enable the Proxy Login rights:
- Click > Administration > Access Management > Users
- Select the user of interest
- Click the [Proxy Login Permissions] button
- By default, no Users or Teams are displayed
- The Default Proxy Login settings grant this user Proxy Login rights to All Users and Teams
- If Users or Teams are selected, then this user has Proxy Login rights to the selected Users/Teams, only
- Click the [Edit] button to modify the Default Proxy Login settings
- Choose the desired Users or Teams
- Click [Save]
- Considerations
-
- The User/Team relationship is additive, meaning that:
- If a Team is selected, all Users on that team are available for Proxy Login by the selected user
- If individual Users are selected, only those individual Users are available for Proxy Login by the selected user
- If a Team is selected, and individual Users in that team are also selected, then the addition of those users makes no difference (because the Users are already members of the selected Team)
- However, if those Users move to a new Team in the future, then this permission will apply to those Users in their new Team
2.9 Deactivate a User
When a user leaves your organization, you manage the change by Deactivating that user. That action frees up a License that can be applied to a new user, while preserving the former user's history of record ownership, activities, tasks, and so on. (The delete operation is not allowed, for that reason.)
To deactivate a user:
- Remove the user from all but one team - see Remove Team Members
- Deactivate the User
This user is now deactivated. The deactivated user no longer appears in User lookups, and the License is now free to assign to another user.
- Note:
To change the number of licenses in your subscription, modify your Subscription Plan.
To make the username available for someone else:
- Change the username to something no one else will ever use.
- For example: NOSUCHPERSION_1.
- The original username is now available for someone else to use.
3 User Settings
Note:
- Empty fields are not shown when viewing user settings. They appear only when editing.
- For a user who is recognized via LDAP Configuration, only the user's Team membership, initial Application, and application Role can be changed. All other information comes from the LDAP directory, where it can be modified.
3.1 Basic Information
First Name User's first name as it should appear in the platform Last Name User's last name as it should appear in the platform Title User's professional title Reports To Manager or supervisor Access Profile The Access Profile assigned to the user Accessibility Mode Enables Accessibility Mode for those whose vision or motor skills are impaired. Employee Number Optional identification number for each employee User License Type Site user (an external user for whom there is no charge) or a Platform User (an internal user).
(This option appears only in a tenant-management domain.)
3.2 Locale Information
Time Zone Choose a Time Zone Code from the drop-down list. Date Format Choose a Date Format from the drop-down list Time Format Choose a Time Format from the drop-down list Locale The user's locale setting. Determines the format for numbers, decimal fields, and percentages. Language User's language. (Only shown if Multiple Languages are specified in Company Information.)
3.3 Login Information
Email The user's email address, used for sending and receiving email through the platform Username Username is a unique name associated with each User. Username is required to Login, can be an email address or an alphanumeric text string. Active Selecting this option indicates that the user account is active Mobile Access Allows a user to access the platform using a mobile device. Single Sign-On This option appears when Single Sign-On is enabled. It allows a user to login to an organization's secure network with a single username and password, and then access the platform without having to log in again. The following options are displayed, depending on the configuration:
- Single Sign-On - Pass Through Authentication
- Supply address information for a custom authentication server.
- Single Sign-On - Delegated Authentication
- Select the checkbox to enable Single Sign-On for the user.
- Single Sign-On - SAML
- A SAML Federated Id field is displayed. A SAML Federated Id is used as authentication across multiple IT systems
- Single Sign-On - Pass Through Authentication
3.4 Team Membership
- This section appears only when adding a new user.
Primary Team The initial Team the user belongs to
3.5 Startup Information
Initial Application The first application the user sees after logging in. Role The user's initial Role in the application. (Additional Roles can be assigned later, using the Application Access settings.) Send Welcome Email A message is sent to the user, welcoming them to the platform, and telling them what they need to know to log in.
3.6 Contact Information
- This section does not appear when adding a new user. Users can fill it in for themselves later, or the admin can fill out by editing the record after the User has been added.
Phone Mobile Phone Fax Street Address City State/Province Postal/Zip Code Country
4 For Developers
When using the REST API to Add a User, the password is optional, and not required. Password policies are implicit and are applied automatically when a new user record is created.
- Learn more: Add a User (Record)