We are having a requirement wherein if an end user is leaving and if user is the owner of any entitlement, then user should be able to add a new owner in its place.
We thought of Enabling the Manage Entitlement Tab in ARS to the end user.
It enabled the user to edit the entitlement owner, but apart from adding the new owner, the end user was also able to update the entitlement attributes as well.
Is there any way by which we can prevent this?
i.e., the entitlement attributes should not be editable except for entitlement owner.
Haardik Verma
Thanks for the quick reply as usual Rushikesh !
We explored the above solution and it is great, but in the case where the leaver x wants to assign ownership of certain entitlements to user y and ownership of some entitlements to users a,b,c and so on.. this method may not come in handy.
We have thought of 2 other solutions,
1) Created an analytics with "map entitlement owner" action and created a dashboard for this analytics.
So when the user is nearing his end date, he is notified about the entitlements he owns and is instructed to go to ars dashboards and map the new entitlement owners.
In this solution, the user has completed flexibility, and everything was perfect but we are facing this issue where the end user is unable to access dashboards. A ticket was raised 2 months ago and no solution has been found yet. The end user, when clicks on dashboard, it gives oops access denied error.
2) The second solution was using "Manage Entitlement" tab in ARS, That I mentioned above, but in this the issue is that end user is taken to entitlement page and will be able to edit every attribute of entitlement.
Can you please help us in finding any other solution?
Requirement is to:
- Leaver should be able to give entitlement ownership to other user(s) separately for different entitlements
- New owner should be notified
Yes, the dashboard and analytics was added to the ROLE_END_USER Sav Role.
We tried giving all possible accesses to that Sav Role, but dashboards were not accessible. The Saviynt ticket representative suggested us to make it a "Read-Only" Role.
We did not think that would work because it made no logical sense. Read only restricts the editability , it should not change what and what not is accessible.
BUT SUPRISINGLY, it worked! Dashboard was accessible to the end user sav role.
BUT it affected everything else. A user having ROLE_END_USER was not able to access many things and was getting access denied at many places, even if he also had admin sav role.
This was a weird error. By turning on the Read Only Sav role, it was naturally expected that many things will become inaccessible and show access denied to any user who had end user role. BUT it made the dashboards accessible.
Since this was not an ideal solution, we did not go ahead with it and Saviynt team is working on it since then.
Hi Rushikesh,
Happy Diwali.
Sorry for the delay in response, we had 3-day holiday.
Attaching screenshot
where the URL is
These are the accesses available for end user sav role for which dashboards are visible but on clicking them, it says access denied
| ADMIN | SUBMENU.ADMIN.users_list | |
| ADMIN | SUBMENU.ADMIN.ecmConfig_show_ANALYTICS | |
| ADMIN | SUBMENU.ADMIN.entitlement_values_list | |
| ADMIN | SUBMENU.ADMIN.dashboard_remaccess | |
| ADMIN | SUBMENU.ADMIN.setuserskeysession_set | |
| ANALYTICS | Analytics Config | |
| ANALYTICS | SUBMENU.ANALYTICS.analyticsConfig_remaccess | |
| ANALYTICS | SUBMENU.ANALYTICS.analyticsHistoryES_list | |
| ARS | SUBMENU.ARS.workflowmanagement_requesthome | |
| ARS | SUBMENU.ARS.jbpmworkflowmanagement_showmyhistoryrequests | |
| ARS | SUBMENU.ARS.jbpmworkflowmanagement_viewopenrequests | |
| ARS | SUBMENU.ARS.workflowmanagement_requesthomedashboard | |
| ARS | SUBMENU.ARS.dashboard_dashboardList | |
| ARS | SUBMENU.ARS.workflowmanagement_remaccess | |
| ARS | SUBMENU.ARS.jbpmworkflowmanagement_remaccess | |
| CAMPAIGN | SUBMENU.CAMPAIGN.entitlement_show_detail | |
| CAMPAIGN | SUBMENU.CAMPAIGN.entitlement_show_tcode | |
| CAMPAIGN | SUBMENU.CAMPAIGN.entitlement_show_tcodej |
The export contains GUID. Is it not sensitive information?
And can you please share your email ID, I'll share both the exports over there.
Sorry for the delay in reply. I was unwell
I have shared the sav role extract via private message.
Hi @rushikeshvartak , issue has been resolved from saviynt's side. Dashboards are working fine now.
But by using dashboard as well, the user gets a list of all the entitlements and owners with the action of "map entitlement owner".
The user has to first use the search box and filter out the entitlements for which he is the owner, and then he is able to map the new owner for each entitlement he owns.
So, in this case, the user is only able to change the owner (which is better than the manage entitlement tab of ARS that allows changing of all entitlement attributes), but for any user.
So, if I am a leaver, I will be able to change the entitlement ownership for any other user and their owned entitlements as well.
So both the dashboard and manager entitlement things have limitations.
Can you please elaborate on this "Technical rule can be used along with analytics report"
But with this, all entitlements ownership will be transferred to only 1 person right?
If I own entitlements a,b,c and want to transfer ownership of a,b to personX and c to personZ , I can't right?
And if we are going ahead with this method and we choose the users's manager to be saved as the "Owner on terminate" attribute,
Can you suggest a way with which this can be automatically updated in the future?
Like If a user's manager is changes, his "owner on terminate" should also change automatically..
(I think we can do this with customn query job but that is being deprecated in newer versions)
Hi @rushikeshvartak ,
We got the Dashboards working. Also, instead of using Run-time analytics, We used USER CONTEXT analytics with "map ent owner" action and made dashboard for it.
It is working perfectly. The end user, when clicks on dashboard, only sees the entitlements he owns and is able to map new owners for those entitlements.
But the only concern now is that there is no record of this action properly tracked anywhere.
The latest run of the analytics history shows the details, but when in future new owners/entielemtns/applications are added, the analytics run has old data.. So there is no track of the change of owner via map action.
Also, the application audit logs only mentions that the owner has been changed via map ent owner action from dashboard,, but does not have detail about the entitlement for which owner was changed, and which owner was changed.
Also, the entitlement itself, does not have detail of the owner change in the history tab of entitlement.
Do you know any way by which we can track the details of this change done via dashboard, and also email the new owner that he is the owner of that entitlement.
