Creating an Administrator Role

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 grants all permissions, minus those for connectors.
• 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.