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 😉
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
New Main Employment
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
Employee Central Effective Dated Entities
Job Information Actions
Onboarding 2.0 or Offboarding 2.0 Object Permissions
Knowledge Transfer Plan
Knowledge Transfer Task
Recommended Link Task
Recommended People Task
Prepare for Day One Task
Equipment Type Value
Configuration for Prepare for Day One Task
MDF Foundation Objects
Onboarding 2.0 or Offboarding 2.0 Admin Object Permissions
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!
Thanks for sharing info more into RBP..it will helpful blog.
Very useful info. Could you pls share more details on how you resolved the Knowledge transfer task.
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:
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.
Catherine, thank you so much for the detailed information!
Tell me, do I understand correctly that you can set up restrictions in the dashboard for different groups of employees: hiring managers, recruiters, HR managers?
Yes it is possible by creating multiple permission groups for external onboarding users based on the required parameter (business unit / dept etc), and then assigning the targets accordingly in the HR / Recruiters users' RBP roles. We have done this by splitting them out according to business unit for HR/Recruiters and Payroll users.
But you have to remember that once the onboardee becomes an employee, that permission is no longer relevant so they wont be visible in the dashboard. In order to still see them in the dashboard after they are converted to employee, you need to include the internal employees in the RBP role targets for the users as well.
Catherine, good afternoon! Thank you for your answer! Can you please suggest notifications for Onboarding 2.0. Is it possible to configure the recipients of emails, the sending schedule? Standard templates are not suitable for our process.
I saw that you met issue that Admin have permission : Employee Export will can not see Onboardees name from Dashboard. How you fix this issue please let me know.