Creating User, Administrator, and Instructor Roles

Permissions in the SAP SuccessFactors Learning system consist of various functions and entities. Each role is associated with a unique set of permissions, enabling organizations to create tailored roles for different user categories, such as employees, contractors, vendors, and customers. This customization allows for precise access control based on user needs.

For User roles, permissions grant access to user-side tiles, menus, and links. For instance, vendors or external users typically do not require access to internal links or specific features like the Curriculum Status page. The Instructor role provides permissions for specific functions within the My Classes tab.

The system includes two default user roles:  DEFAULT USER and LEARNING_USER. These roles come with preconfigured permissions. However, it is advisable for customers to create custom user roles instead of relying on these defaults. By doing so, customers can control which new features to enable with each update, rather than automatically opting into new functionalities.

The default user role includes all possible permissions, making it a best practice to copy it to create a customized user role. Once the role is copied, the administrator can remove any permissions that are not needed for users. For example, if a customer does not utilize features like Commerce, user-generated content, or peer-to-peer recommendations, those permissions can be easily removed from the custom user role. On the other hand, if a customer wishes to enable specific functionalities for certain users—such as Personalized Recommendations, Training Planner, or Gamification—then the corresponding permissions must be added to the user role for those individuals.

To integrate user data into the SAP SuccessFactors HCM application, follow these steps:

1. Ensure User Data is Available: First, make sure that the user data is already present in the SAP SuccessFactors HCM application.
2. Grant Permissions: Next, assign the necessary permissions for the user to access the Learning module within the SAP SuccessFactors HCM application.
3. Run User Connector SF Process: Finally, execute the User Connector SF process. This process will transfer the user data from the SAP SuccessFactors HCM application to the SAP SuccessFactors Learning system.

As a result of this process, user entities will be created in the SAP SuccessFactors Learning system. These users will then gain access to the Learning module based on the permissions set in the HCM application. Users can easily access the Learning module from a dropdown menu.

There are multiple ways of assigning a role to the user entity:

1. User entity: This is a manual method of assigning or changing a User Role from the user entity. (Choose a role from the Role dropdown on the User Details tab).
2. Connector: When importing users into the SAP SuccessFactors Learning system through the Connector job, it is possible to assign a Role ID to user entities. If the Role ID is invalid or there is no role assigned to user, then the connector defaults to the value in the configuration file (System Administration → Configuration → System Configuration → CONNECTORS → sfuser.connector.defaultValue.studentRoleID).
3. Import Tool: When importing users through Import tool, the Role field is required. Therefore, it is not possible to import the users without specifying the Role ID.
4. Assignment Profile: This is an automated method of assigning a Role to users. Assignment Profiles allows us to create dynamic groups of users based on their HR attributes and assign them a specific User Role.

A user’s primary manager is identified in the Primary Manager field within the user entity. This process of assigning the primary manager can be done either manually by an administrator (User Entity → User Details → Primary Manager) or by the connectors.

Unlike administrators, users, and instructors, there are no separate roles specifically for managers. Once a user is selected as a primary manager, the SAP SuccessFactors Learning system automatically grants them the Manager permissions found in the My Team section of the user’s User Role. The My Team section contains the permissions for the actions the primary manager can perform.

The User Proxy Role defines the permissions that a manager can assign to a delegate. When a manager selects a user to act as their delegate, they can choose to either:

1. Assign Specific Permissions: The manager can specify exactly which permissions the delegate will have.
2. Use Predefined Permissions: Alternatively, the manager can opt for a standard set of permissions that are already established within the User Proxy Role. This allows managers flexibility in how they empower their delegates.

The SAP SuccessFactors Learning system enables customers to establish multiple administrator roles and, if needed, implement security domain groups. When adding administrator accounts to the Learning system—either manually or via the Administrator Connector, one or more roles can be assigned to each account. This functionality allows for comprehensive control over an administrator's capabilities within the system, including the ability to add new roles or remove any that are deemed unnecessary.

1. Create a Template Role: Identify and create a template role. In the description, clearly outline the permissions and restrictions based on customer requirements.
2. Add Permissions: Carefully add necessary permissions for add/edit/view/copy/delete actions. Ensure to include related permissions; for example, if adding items to a library, include permissions to search items and libraries.
3. Remove Restricted Permissions: Do not add permissions that are typically reserved for the system administrator, such as adding/editing/deleting reference entities. Familiarize yourself with reference entities by reviewing the lists under each reference menu.
4. Include Reporting Permissions: If the role will run reports, ensure it includes access to reports, full search capabilities, and the critical View User Background Job permission from System Administration.
5. Copy and Apply Security Groups: After testing the template role with the customer, copy it and apply security domain groups to each copy.
6. Apply Security Domain Groups: Security domain groups can be applied by function, entity, or permission. Different groups may be assigned to different permissions; for instance, an administrator may search for items across the security domain but only create classes in a specific domain.
7. Test the Role: Create an Administrator account with just one assigned role. Log in as this administrator to verify what they can do, what they cannot do, and where they can view or add entities based on applied security domain groups.

Administrators can have different types of responsibilities depending on the organization's requirements (internal factors) and the enterprise environment (external factors). A typical Administrator structure is built from Super Administrator who has unrestricted access to the entire Learning system, and other administrators whose access is determined by the split of roles and responsibilities within the organization.

There are two main administrator default roles:

• ALL: This role has all permissions.
• ALL_CONNECTOR: This role has permissions for connectors.

These default roles come with preconfigured permissions, which may change with new updates. To maintain control, it's best to create custom copies of these roles instead of using the defaults. This allows organizations to specify exact permissions for each role.

For administrators to perform their tasks effectively, permissions are essential for controlling access to specific features and functions within a system. When determining which permissions to assign, customers should consider the entities the administrator will manage and the functions they need to perform.

Best Practices for Assigning Permissions:

1. Limit access to entire sections:
   • As a best practice, do not grant entire sections of permissions to a role except for specific administrators when necessary.
   • The Search category is typically necessary for most roles, as it allows administrators to search for various entities.
   • The System Administration category should only be assigned to the highest-level System Administrator or similar roles.
2. Permissions for creating entities:
   • If a role involves creating entities such as Items, Curricula, and Programs, relevant permissions will be found in the Learning Activities section.
   • This role will likely require permissions to add, edit, copy, delete, and view these entities.
   • Permissions for searching for various entities can be found in the Search section.
   • Generally, this role will not need permissions related to adding or editing reference values; therefore, only Search and possibly View permissions should be granted for reference values.
3. Permissions for user management:
   • For roles that involve managing users, such as assigning learning needs or entering user information in view or edit mode, permissions from the People Management section are necessary.
   • Similar to the previous case, this role typically does not require permissions to add or edit reference values related to users; thus, only Search and possibly View permissions should be assigned.

The permissions in the Search categories are generally safe to use in most administrator roles. If a role will need to search for various entities, including learning entities, users, and references, the Search permissions should be included. If a company does not use certain entities at all, such as for legacy Plateau Performance or Commerce, those Search permissions should be removed from the role(s).

The permissions in the Reports category include all the pre-built reports, as well as some permissions specific to administrators who will be working with Report Designer (PRD) and custom reports. These special permissions include Import/Export Reports, Publish/Unpublish Reports, and Add/Edit Report Group. As custom reports are created and imported, the administrator role may be edited to include the new permission specific to that custom report. The View User Background Job permission is from the System Administration.

While other administrator roles may require the ability to view Connector APMs to check their scheduled run times, only a select few high-level administrators will need the authority to schedule them. There is a default role called ALL_CONNECTORS, which includes edit permissions for this section. Only those administrators who need to schedule connectors should be assigned the ALL_CONNECTORS role.

Because references are values that are shared globally within the company, certain roles are restricted from adding, editing, deleting, and copying them. While other administrator roles may require search and view permissions for these entities, only the system administrator role or a similar all-encompassing role is authorized to create and edit references. Some references may be automatically populated through connectors or import data tools, while others must be entered manually. Examples of references include item types, completion statuses, assignment types, categories (previously known as subject areas), employee statuses, employee types, and job codes.

When adding permissions to an administrator role that is not the system administrator, it is recommended to avoid granting permissions that would allow them to add or edit references. However, it is important to ensure that most or all administrator roles can search for references, as they will need this capability when searching for other entities. For instance, when searching for users, administrators should be able to search by job codes, and when searching for items, they should be able to search by item type.

To provide a user with access to the Instructor interface, follow these steps:

1. Create an Instructor entity: Set up an Instructor entity for the user and assign the desired instructor role.
2. Associate the Instructor entity with the user: Choose the user in the Related User field of the Instructor entity.
3. Authorize to Teach: Use this tab to include the instructor as a resource for one or more class time slots.
4. Record Completions: If the instructor will be adding history records for ad hoc classes, ensure they are authorized for one or more relevant items.