--- title: "Attribute Fields - Best Practices" slug: "attribute-fields-best-practices" description: "Best Practices for creating and managing user Attributes in Rapididentity" tags: ["RapidIdentity Cloud", "Attributes", "Best Practices", "Administrator"] updated: 2023-06-26T21:08:51Z published: 2023-06-26T21:08:51Z canonical: "help.rapididentity.com/attribute-fields-best-practices" --- > ## Documentation Index > Fetch the complete documentation index at: https://help.rapididentity.com/llms.txt > Use this file to discover all available pages before exploring further. # Attribute Fields - Best Practices ## Best Practices for Managing User Attributes RapidIdentity Cloud provides a robust schema that allows for the management of user’s identities. The RapidIdentity Schema has been designed in order to allow for multiple attributes to be stored in order to make decisions about a user's access and entitlements. Even though the design allows for multiple fields, the recommendation is to only store attributes that are needed to manage and maintain a user's identity and what they need access to. The concept of Least Privileged Access should be taken into consideration when deciding on which attributes to send to RapidIdentity. #### Things to consider: - What are the attributes used for? - Do downstream provisioning applications need this information? - Are the attributes being store for Authentication (AuthN) or Authorization (AuthZ) - Do the attributes allow for relationships between two identities? - Do they provide access to entitlements - Can they be used in Roles Based Access Controls (RBAC) or Attribute Based Access Controls (ABAC) Identity Automation can make recommendations as to what should be provided, and what is needed for a successful identity management implementation. We look at the transferring of data to be a partnership between the two parties in order to meet the successful needs of the implementation. Below you will find a table of requirements for RapidIdentity as well as suggestions for attributes that should be provided if they are available in your source of authority. ### Schema Overview The Current version of the RapidIdentity Schema can be found here: [RapidIdentity Directory Schema](/v1/docs/rapididentity-cloud-directory-schema) Important to Note: Even though LDAP is referenced, it is a LDAP implementation configured by Identity Automation that can be replaced at any time for more efficiency and functionality with no impact to the environment. All implementations and updates should include a RapidIdentity certified administrator. ### Attributes | RI Attribute | Friendly Name | Identity Need | Description | | --- | --- | --- | --- | | givenName | First Name | YES | First Name of a person. The purpose is to identify a user's identity with a person. | | idautoPersonMiddleName | Middle Name | No | Middle Name of a User. If available this is highly suggested to differentiate between two individuals with the same first and last name | | sn | Last Name | YES | Last Name of a person. The purpose is to identify a user’s identity with a Person | | displayName | Display Name | YES | The Full Name of a user, consisting of all named attributes. | | idautoPersonStuID | SIS ID | YES | The Student Information System Unique Identifier | | idautoPersonHRID | HR ID | YES | The Human Resource System Unique Identifier | | idautoPersonSourceStatus | Status | YES | Denotes Whether a person is Active or Inactive in a source system. This can be Active or Inactive, A or I, or other attributes that can be used to derive an active or inactive status. Examples are FTE = Active, Retired, Terminated, or Suspended = Inactive | | mail | E-Mail | NO | Typically derived by RapidIdentity. Can be provided by the system if they own the Email address generation. | | mobile | Phone Number | NO | The Cell phone number of a user. This **IS** needed if providing Password Reset functionality via SMS. | | idautoPersonHomeEmail | Personal E-Mail | NO | A personal email of the user, **NEEDED** if providing Password Reset Functionality via EMail. | | manager | Manager | NO | The Manager of the user. Typically provided in the form of an ID, and derived to a user specific ID in RapidIdentity. This will allow for delegated access from the manager to the end user. | | idautoPersonDeptCodes | Department Code | YES | Department of a staff user. Used for groupings, and ABAC | | idautoPersonLocCodes | Location Code | YES | Location of a User. Used for groups and ABAC | | idautoPersonJobCodes | Job Codes | YES | A Persons Job Code. Used for Groups and ABAC | | idautoPersonSchoolCodes | School Codes | YES | Schools a person is associated with. This is MANDATORY when using Analytics within RapidIdentity | | idautoPersonSchoolNames | School Names | YES | School Names a person is associated with. This is MANDATORY when using Analytics within RapidIdentity | | idautoPersonJobTitle | Title | NO | TItle of a User. Useful in identifying a user outside of a code | | idautoPersonGradeLevel | Grade | YES | Grade Levels associated with an identity. | | idautoPersonEmployeeTypes | Roles | YES | The roles a user is associated with on a granular level. Example - Teacher, Admin, Para | ### Derived Attributes *Derived Attibutes are created by the RapidIdentity system.* | RI Attribute | Friendly Name | Identity Need | Description | | --- | --- | --- | --- | | idautoID | idautoID | YES | Unique Identifier for RapidIdentity | | idautoPersonSamAccountName | sAMAccountName | YES | The username of a user, that is synced to secondary systems, such as Active Directory. This follows Active Directories standards of 20 characters and unique per system. | | idautoPersonUsernameMV | Usernames | YES | All Usernames that a user can login with to RapidIdentity. By Default provisioning takes into account mail, and idautoPersonSamAccountName. Unique ID’s CAN and are suggested to be included. If this is included you must make sure the ID is unique across various platforms. Example. HR System and SIS may have the same ID for two different users. This cannot be used in idautoPersonUsernameMV | | mail | Mail | YES | This is typically derived by the system and synced downstream. It is also referenced above depending on the deployment of the RapidIdentity Platform. | | EmployeeType | Role | YES | Based on the source of Authority. **MUST** be Staff, Student, Sponsored or Parent | Notes These are all suggested attributes for a successful deployment of an Identity and Access Management System and are found in all standard HR and SIS platforms. Not including some of these attributes will limit what you can do with a platform and make it difficult to scale the platform moving forward. With that said, Attributes are easy to add to the system, but business rules and processes may need to be adjusted and retested within the system. ### OneRoster Mappings *The attributes below are derived from the users endpoint.* | OneRoster | RapidIdentity | | --- | --- | | sourcedid | idautoPersonStuID | | status | idautoPersonSourceStatus | | givenName | givenName | | familyName | sn | | middleName | idautoPersonMiddleName | | orgs -> sourcedId | idautoPersonSchoolCodes | | orgs -> href -> name | idautoPersonSchoolNames | | grades | idautoPersonGradeLevel | | phone | idautoPersonHomePhone | | username | idautoPersonSystem1ID | | email | idautoPersonHomeEmail | ## Related - [Global Attribute List](/global-attribute-list.md) - [Configuring Global Search - Requirements](/global-search-configuration-requirements.md) - [Configuring a Dynamic List Attribute](/configuring-a-dynamic-list-attribute.md)