Announcing the Saviynt Knowledge Exchange unifying the Saviynt forums, documentation, training,
and more in a single search tool across platforms. Read the announcement here.

User udpate workflow - how to check if manager change was requested?

yogesh
Regular Contributor III
Regular Contributor III

Our use case is to check whether a manager update was requested from the user update form and based on that send approvals to the current manager (if other user attributes were updated but manager stayed the same) or the changed manager(when manager was also updated along with other attributes).

How can we get the values of the current managers username and old managers username in the if-else condition? and then in the custom assignment block?

6 REPLIES 6

rushikeshvartak
All-Star
All-Star

rushikeshvartak_0-1653586881182.png

Use custom query  in custom assignment 

 


Regards,
Rushikesh Vartak
If you find the response useful, kindly consider selecting Accept As Solution and clicking on the kudos button.

amit_krishnajit
Saviynt Employee
Saviynt Employee

You can use following expression in the if-else block:

dynamicAttributes.get('owner') != null and dynamicAttributes.get('owner') != '' and user.owner != dynamicAttributes.get('owner')

And you can re-direct approvals like the following:

amit_krishnajit_0-1653626799496.png

owner attribute holds the username of the manager in the above use-case 

Approval goes to custom assignment when the owner/manager is changed, else it goes for user's manager approval block. 

 

Thanks,
Amit

This will work only when you update owner along with managar 

When u change manager  from update user details tile manager dynamic attributes is populated in raa table


Regards,
Rushikesh Vartak
If you find the response useful, kindly consider selecting Accept As Solution and clicking on the kudos button.

The owner attribute is used for storing and updating the user's manager's username - this will automatically populate the value for the manager field(which is of type bigint in the backend and stores the user's manager's userkey).

When you point any dynamic attribute in the create/update user form to the "owner" attribute, the value for that can be accessed using the expression "dynamicAttributes.get('owner')" - even if it's stored in the request_access_attrs table, it can be easily accessed in the above manner in the if-else block in the workflow. 

In case of user update, the current value stored in any user property can be retrieved using the following expression "user.<<attribute_name>>" e.g., user.owner, user.customproperty1, etc. 

Hence you can compare the value passed in request form during update to the value stored in the database, like the following: dynamicAttributes.get('owner') != user.owner

Hope this will clarify your query. 

 

 

Thanks,
Amit

i do agree that owner is getting updated as username once manager is updated but once request is submitted only manager attribute is populated in raa.

Request :

rushikeshvartak_1-1653665150615.png

 

DB :

rushikeshvartak_2-1653665174559.png

 

 


Regards,
Rushikesh Vartak
If you find the response useful, kindly consider selecting Accept As Solution and clicking on the kudos button.

This when you have mapped "manager" attribute in user's column in dynamic attribute. And still you can compare the old and new value for manager like the following:

dynamicAttributes.get('manager') != null and dynamicAttributes.get('manager') != '' and user.manager != dynamicAttributes.get('manager')

And the point that you are making that the new manager value is stored in the request_access_attrs table - I agree to this and also confirm that this is accessible in the if-else block in the workflow if you invoke it like the following :  dynamicAttributes.get('manager').

Basically the point here is - any dynamic attribute which is mapped to a user column is accessible in workflow (for the request, even if the value is stored in request_access_attrs table until the request has been approved, it's still accessible in the workflow). 

Hope this clarifies. 

 

Thanks,
Amit