Unlike the typical SAP HR consultant (maybe), I have a soft spot for security. I’ll admit when I first got into SAP HR, security wasn’t my top priority when I was working in the system. That’s not to say I was giving SAP_ALL out to all users and letting the chips fall where they may, but security wasn’t my direct concern. I always had an SAP Security resource to work with who worried about the ins and outs of proper HR security roles in SAP. It wasn’t until I was witness to some big security blunders around SAP HR data and then led my first implementation of Structural Authorizations in SAP HR that I started to appreciate the nuances of proper security with respect to flexibility for the business and end user.
It’s this background of mine that might have me more interested in the security aspects of SuccessFactors than the typical consultant. In this blog I want to highlight a concept employed in SuccessFactors Learning around administrator security that, if implemented properly, can provide much needed flexibility with a high level of security for learning organizations. And since my background is SAP HR, I’ll make parallels here for comparison sake between SuccessFactors and SAP to illustrate things further for those of us that may have experience on both sides of the fence.
With any LMS, someone is going to have to administer the system. Depending on the maturity of an organization’s learning department, that may be one individual or many, and whoever those administrators may be, they must have the proper access in order to do their jobs within the LMS. SuccessFactors Learning provides a security model for administrator access consisting of three components; 1) Domains, 2) Domain Restrictions, and 3) Roles. In this blog, I want to focus on the use of Domains and how they are utilized within admin security roles to help restrict security appropriately while providing flexibility for the learning organization.
The first exercise in the security implementation process for SuccessFactors Learning focuses on defining Domains and identifying Domain Restrictions. Domains control what admins can see with respect to what SuccessFactors calls ‘domainable entity records’. Numerous entities in SuccessFactors Learning are ‘domainable’ (meaning they can be assigned to a specific domain), including Items, Curricula, Assignment Profiles, etc. The first step in the setup of admin security in SuccessFactors Learning involves defining the level of granularity that these learning entities should be secured. This level of needed security for administrative purposes is used to create a Domain Tree. A Domain Tree can be thought of as a high level organization structure that represents the levels of granularity needed for learning administration security. These levels could be geographic based, departments, divisions, business units, or any other logical classification needed for segregating entities for admin security purposes. As these domainable entities are created/maintained in the LMS, they are assigned to respective domains as required.
From an organization’s defined Domain Tree, Domain Restrictions can be utilized to group one or more domains for use within admin security roles in order to determine the areas of access a role will give to an administrator. These Domain Restrictions can be used to limit admin access to area of responsibility only, thereby telling the LMS where the workflows (i.e. – permissions) may be performed by an admin. This is where the flexibility of admin security can really come to light in SuccessFactors Learning, allowing organizations to define broad areas of responsibility for some functions/entities and narrow ones for other areas to the same admin if necessary by creating and applying various Domain Restrictions to functions/workflows within admin security roles.
To help illustrate the use of Domains and Domain Restrictions in SuccessFactors Learning admin security, the simple example below can be utilized to show defined domains, a domain tree, and domain restrictions for a fictional organization with learning administration security needs across the US and Europe for various divisions.
Referencing the domain structure/tree above, a top level domain (Eric Corp) for our organization gives way to 1st level domains based on geographic regions (US/Europe). Underneath these geographic based domains we then have a 2nd level of domains representing divisions within the organization (HR/Sales/Operations). These divisions are found across each geographic region. Notice how the domain tree is itself a hierarchy, very similar to an org structure, and the domains within the tree can be representative of areas, departments, functions, etc., whatever is appropriate for segregating administrator access in SuccessFactors Learning. Imagine then assigning domainable entities to these domains as needed (i.e. – an Item/Course to the US domain, an Instructor to the European Sales domain, etc.).
The red boxes in the diagram above represent Domain Restrictions (i.e. – groupings of domains) that we can use for administrative security purposes within SuccessFactors Learning. Domain Restrictions 1 and 2 in the diagram represent our US and European functions, respectively. These Domain Restrictions include the higher level geographic domain plus the respective lower level divisional domains under each region. With these domain restrictions, we could provide admin access that allows administrators to do certain functions for entities within this domain restriction only, like creating Scheduled Offerings (entity) within the LMS for only Items that fall within these areas (i.e. – creating scheduled offerings for items held within the US or European HR, Sales, and Operations divisions only).
Domain Restrictions 3, 4, and 5 represent divisions across our overall organization (i.e. – HR, Sales, Operations) regardless of geographic region. This could be used to grant administrator access to those individuals that may need to report on users, upcoming training, and training history within these divisions only (i.e. – a user in the Sales division that needs to report on employees in Sales and their training history regardless of geographic location, but shouldn’t be able to see details of employees outside of Sales).
Hopefully this basic example gives you a general idea of how Domains and Domain Restrictions can be used for administrator security in SuccessFactors Learning. While my goal here is to provide you with a general understanding of using domains in admin security in SuccessFactors Learning, there is no one size fits all approach to utilizing domains for organizations implementing the LMS. Every organization is different and will approach admin security in a variety of ways. It is not uncommon to have only one top level domain and just a few admins who can perform all functions universally across the organization. On the other hand, large organizations with more complex training admin requirements may have multiple admins responsible for a variety of tasks that must be limited accordingly within the organization, thus leading to a more robust domain structure. Bottom line I have for anyone implementing SuccesssFactors Learning, keep it simple when defining required domains. Do not over engineer the approach to domains. While there is great flexibility that can be provided here, over complicating the domain structure can lead to confusion among admins as they create and assign entities to domains. Properly identify the necessary admin security required for your HR business processes and build your domain structure accordingly.
And finally, as promised, in making a comparison to SAP security for Learning Solution/Enterprise Learning, SAP security around HR Objects for training purposes (i.e. – Course Groups, Course Types, Courses, etc.) only goes so far. Basic SAP authorizations can be used to allow access to specific object types, but not specific objects themselves unless you utilize structural authorizations. Certain scenarios can become problematic in SAP, with one common example involving limiting a user’s access to only specific parts of the course catalog. Structural authorizations can be leveraged in addition to the basic authorizations in SAP to meet requirements like these. For anyone familiar with Structural Authorizations, think of Structural Profiles in SAP like Domain Restrictions in SuccessFactors Learning. Both of these concepts can be utilized to group HR Objects (SAP) or Domains (SuccessFatcors) together in order to assign to security roles and influence what a user can see. While I am a fan of the use of Structural Authorizations in SAP HR and have presented the topic at several SAP HR conferences in the past and written an article on the subject (How to Use Structural Authorizations for Effective HR Strategy and Security), implementing structural authorizations is no small task in and of itself. SuccessFactors Learning provides a simple, straightforward approach here around admin security that provides great flexibility and a high degree of security with much less effort to design and setup.
