# Security Section — Learning Path _Learning Paths › Security Section_ This learning path is for security administrators and application owners responsible for maintaining access in the Security Section. You will learn how to manage individual users, organize users into teams, and create or update roles using the available security administration screens. ## Learning objectives - By the end of this path you can manage individual user records in the Security Section. - By the end of this path you can create and maintain teams for groups of users. - By the end of this path you can create new roles to support access-management needs. - By the end of this path you can review and update existing roles as security requirements change. - By the end of this path you can choose the appropriate security screen for a user, team, or role maintenance scenario. ## Prerequisites - Access to the Security Section of the application. - Permission to view and maintain users, teams, and roles. - Familiarity with your organization’s access-management policies, including who should be assigned to teams and which role changes require approval. ## Module 1: Establish and maintain individual user access **Goal:** Learn to locate, add, and maintain the user records that underpin security administration. ### Lesson 1.1: Review the users you are responsible for When you need to confirm which individual user records require attention, begin with the central [Users](doc:users-guide-2) screen. Use this screen as the starting point for user administration, then open the relevant user record in [Users](doc:users-guide-2) to review or maintain that person’s security record. **Practice task:** Open [Users](doc:users-guide-2) and identify one user record you would review before making an access-related change. ### Lesson 1.2: Add or update a user record When a new person requires an application user record, use [Users](doc:users-guide-2) to create it. When an existing person’s security record needs maintenance, open that person from [Users](doc:users-guide-2) and use [Users](doc:users-guide-2) to make the required update. Use the new-user screen only for new records and the edit screen for changes to existing records. **Practice task:** Describe whether a new starter and an existing user needing a correction should be handled in [Users](doc:users-guide-2) or [Users](doc:users-guide-2). ## Module 2: Manage security through teams **Goal:** Organize users into teams so group-based security administration can be maintained consistently. ### Lesson 2.1: Review the team structure When you need to understand the existing group structure before changing access, start on [Teams](doc:teams-guide). Review the available teams and select the team that is relevant to the business group or access scenario you are working on. **Practice task:** Open [Teams](doc:teams-guide) and select a team you would investigate before changing its membership. ### Lesson 2.2: Create a team and maintain its users When a new business group needs to be represented in security administration, create the group using [Teams](doc:teams-guide). To maintain the people associated with an existing team, open the team’s [Users](doc:teams-guide) screen from the Teams area. This separates creating the team itself from maintaining the users connected to that team. **Practice task:** For a newly formed department, identify the screen you would use to create the team and the screen you would use later to maintain its users. ## Module 3: Design and maintain roles **Goal:** Create and update roles to keep security aligned with changing responsibilities and governance needs. ### Lesson 3.1: Review existing roles before making a change When a request for access arrives, first determine whether an existing role can meet the need. Start from [Roles](doc:roles-guide-2), then open the appropriate role in [Roles](doc:roles-guide-2) to review and maintain the existing role. This approach helps avoid creating unnecessary duplicate roles. **Practice task:** Open [Roles](doc:roles-guide-2) and identify the role you would review before deciding to create a new one. ### Lesson 3.2: Create a role for a new access requirement When no existing role supports an approved access requirement, create a new role in [Roles](doc:roles-guide-2). Use the role-creation screen to establish the new role, then return to [Roles](doc:roles-guide-2) to confirm it is available among the maintained roles. Use [Roles](doc:roles-guide-2) later when the role requires an update. **Practice task:** State which role screen you would use for a brand-new role and which you would use to revise an existing role. ## Final assessment 1. A new employee needs an application user record. Which screen should you use to create the record? 2. An existing user’s security record needs to be maintained. Starting from the user list, which screen should you open for the update? 3. A new department needs its own security grouping, and its members will be maintained over time. Which two screens support these two tasks? 4. A request asks for access that may already be covered by an existing role. What is the appropriate screen sequence before deciding to create a role? 5. A role already exists but must be changed to reflect a revised business responsibility. Which screen should be used, and why is it preferable to creating a new role? ### Answers 1. [Users](doc:users-guide-2) — it is the screen for creating a new user record. 2. [Users](doc:users-guide-2) — use it to maintain an existing record after locating the user in [Users](doc:users-guide-2). 3. [Teams](doc:teams-guide) and [Users](doc:teams-guide) — create the team first, then maintain the users associated with it. 4. Open [Roles](doc:roles-guide-2), then review the relevant role in [Roles](doc:roles-guide-2) — this confirms whether an existing role can meet the requirement before a new one is created. 5. [Roles](doc:roles-guide-2) — it is intended for maintaining an existing role, avoiding an unnecessary duplicate role.