Hello Pavani,

Ideally, this behavior can be observed because of the lock on the work object not being held while you are trying to save the object. Make sure you acquire the lock before updating and save.

There can be other scenario where you might be releasing the lock ( using commit method) before this commit actually happens. To get the lock try using the method 'Obj-refresh and Lock"  before commit step.

Best Regards,

Mounika

Hi  Pavani,

This could mainly occur if the operator y has a new access role name defined.

In the access role name of the operator y - please add the org-fw-application-data class or the data class that is failing above and give access 5 for Read, write and Delete instances.

Save the access role name and test the scenario again.

This should make it work.

Make sure these changes are exported in your product package when you do the code migration.

Regards

Sri

Hi Pavani,

I still believe the issue is to do with access role, as with dev role you can save it but not via the manager portal.

Questions:

Have you created a custom data class (specific to your application) for the screen that is being saved?

Was there a database table created on the backend for that data class? If so follow the below steps.

Steps to be followed:

Click on add icon at the end of the list in the role defined for the Managers and verify the application specific data classes are listed in there with appropriate privileges.

It will bring up the below dialog, add the application specific data class name and provide the access as below.