Skip to Content
Personal Insights

RBP Challenges implementing Onboarding 2.0

We are about to go live with our first Onboarding 2.0 implementation next week – and I think the first in New Zealand, with our second one to follow in a few weeks. Unexpectedly, our biggest challenges were with RBP.  In this blog I’ll share with you the challenges we faced, and the solution to those challenges.

Being active in the Onboarding 2.0 Forum on SF Partner Delivery Community, ONB learning room and, attending learning room live sessions hosted by Mark Tristan Ayson, and reading blogs prepared me for what to expect. Or so I thought!  Onboarding 2.0 was released to GA in December 2019, and I gained my certification in January 2020. Being a brand new product there was always the expectation it would have the odd bug, and it did not disappoint 😉

Unexpectedly, our biggest challenges were with RBP. There were various issues with the dashboard for Managers and Recruiters/HR.

Issue 1: we saw was that all employees from across the business were showing up in the dashboard for Hiring Managers. Right away that was a no go!
Issue 2: The names of the new hires and the titles of the tasks had disappeared – but the Managers could still complete the tasks!
Issue 3: The name of the Hiring Manager was not showing,
Issue 4: The templated text in the welcome message and the offboarding tasks to announce termination message and write farewell message went missing when the manager was attempting to complete the tasks!

Offboarding had a specific issue related to the Knowledge Transfer tasks, when assigned to employees who didn’t have MSS or Admin access. The solution to that was an additional employee self-service role, specifically for the Offboarding KT task, so that we could make the target everyone in their department, without including the existing ESS access to the others in their department. Without that role, they could receive the KT tasks, but could not process it – the task just hung there. And for the Offboardee, they could see their Offboarding Tasks tile, but not see who the tasks were assigned to.

With the help of our assigned SAP APAC Regional Implementation Group (RIG), we were able provide (and remove) the necessary permissions for hiring managers and administrators, so that 1. Hiring Managers could only see their direct reports, 2. could see all the names and descriptions of the new hires and tasks, and the ability to complete the tasks successfully, and the Offboarding tasks functioned properly.

The customer is already live on EC & ECP, so we had to take into account their existing EC design and RBP roles, and try to minimise the changes to EC as much as possible.

There were various issues related to field validations in the background when performing things like cancel onboarding, i.e., if there are fields the customer has made mandatory that are used in this process, the process fails. So, it is important to work closely with your EC consultant!

Over time, we found that adding more and more permission to the Manager Role was solving each issue. The Manager role did require some admin ONB permissions which we didn’t expect.

There were also certain administrator permissions that had to be removed from existing EC roles, such as:

Metadata Framework > Admin access to MDF OData API
Manage Integration Tools > Allow Admin to Access OData API through Basic Authentication
Manage User > Employee Export

Ideally, you wouldn’t assign permissions like that to general self-service users, but, they were there.

Now, the mention of removing Employee Export might have raised a red flag with you, and rightly so! The removal of Employee Export will cause issues for HR / administrators, who also need to access the dashboard. They will no longer be able to run the employee export report. You would need a work around of providing the employee export to another admin role that does not require access to the ONB dashboard. I came across an improvement request on the Customer Influence for SAP to provide a solution to this. Have a look and give it a vote to save us all some heartache 😉

https://influence.sap.com/sap/ino/#/idea/261281

Our customer also had some unique requirements in regards to restricting down which new hires the Recruiters/HR saw in their dashboard down to external users in specific Business Units. We didn’t know if we could do this, but by the magic of RBP, we achieved it for them.

With all RBP issues resolved, our Manager role looks like this:

General User Permission
User Login

Employee Data
Employment Type
Location
Restricted Manager
Last Name
Hire Date
Manager
Job Code
Custom Manager
Department
Division
First Name
Middle Name
New Main Employment
Recruit Date
Photo
Status

Employee Central API
Employee Central Foundation OData API (read-only)
Employee Central HRIS OData API (read-only)

Homepage v3 Tile Group Permission
Homepage v3 Onboarding 2.0 tile group

General User Permission
Company Info Access
User Search

Employee Central Effective Dated Entities
First Name
Last Name
Middle Name
Job Information Actions
Position
Entity
Business Unit
Division
Department
Location
Supervisor
Job Classification
Job Title

Onboarding 2.0 or Offboarding 2.0 Object Permissions
Asset Task
Buddy Task
Checklist Task
ONB2DashboardFilter
Equipment Task
Knowledge Transfer Plan
Knowledge Transfer Task
Recommended Link Task
Meeting Task
Process
ONB2ProcessResponsible
ONB2ScheduledMessageActivity
Recommended People Task
Prepare for Day One Task
Equipment Type
Equipment Type Value
Process Trigger
Configuration for Prepare for Day One Task

MDF Foundation Objects
BusinessUnit
Cost Centre
Department
Division
Job Classification
Job Function
Legal Entity

Onboarding 2.0 or Offboarding 2.0 Admin Object Permissions
Onboarding Programme
ONB2Config
ONB2OffboardingActivitiesConfig
ONB2ResponsibilityConfig

There were several other challenges as you can imagine with a brand new product, such as figuring out business rules logic, limitations in Email Services and a few other areas, but RBP was by far our biggest challenge!  And from what I have seen on the Partner Community Forum and Onboarding Learning Room, we are not alone on that!

If you can get the RBP right, and you have a customer that is not averse to being an early adopter, I believe Onboarding 2.0 is the way to go. With future enhancements to come, I look forward to seeing the product advance and provide more flexibility and functionality!

 

7 Comments
You must be Logged on to comment or reply to a post.
    • Hello Sunil

      For the Knowledge Transfer task, we created an additional employee self-service role specifically for Offboarding.  We are also going live with RCM & LMS at the same time, with the target for those permissions being "everyone in self".  With the Offboarding permissions in the same role, target "everyone in self" is what caused the issue.

      The target needs to cover other employees for who the tasks are going to be for / assigned to.  So in this case, we need to make the target All employees.  It could also be a target of granted users department / division etc, to restrict it down if it will only ever be shared within departments etc.

      This is all we have in the offboarding specific self-service role:

      Onboarding 2.0 or Offboarding 2.0 Object Permissions
      • Knowledge Transfer Plan:  View/Edit
      • Knowledge Transfer Task:  View/Edit
      • ONB2ProcessResponsible:  View

      For us, the target is safe to set to all employees, because it is only related to offboarding permissions, and only when they are a participant.

      Hope this helps!

  • Thanks for your prompt response Catherine. Will try this & hope it will resolve the issue.

    We are facing a bunch of other RBP related issues in ONB 2.0.Is there a way to reach out to you with more questions?

     

  • Catherine Merrick  : Thank you for sharing the information. . How did you restrict the HR Admin/Recruiters to view the Candidates only to there departments/ Business Unit in Onboarding Dashboard. .  How the Target Permission Group and assignment is granted. Could you please highlight and provide more details on the same.

    • Hello Abdul Salam

      The first part was to create multiple external user groups in manage permission groups per business unit, to capture external users being hired into relevant business units, as this was requirement for splitting out the target users for the customer.  It was only 4 groups.

      Next was to include the permissions to the HR/Recruit role, and then "Add for external target population" the newly created external user group.  We added one for each HR/Recruiter role, selecting the relevant external user group.