Disable users

[#1]

Hi All,

Hope you guys are doing well.

I want to disable users who left the organization or no longer on project. If I disable users who already left, all the workflow which are created by them and running will throw error and go on paused state.

I do not want this to happen. Is there any way to achieve this by not doing lot of manual work(restart  workflow by another user).

One of the solution could be change "created by" attribute. Can anyone help me how to change created by attribute of workflow.

Any other solutions are welcome.

Thanks in advanced..!  

[darpan9935 · Accepted solution]

Hi Darpan,

So the simplest method is simply to look up the last modified by field for your workflows.  If the user(s) you wish to disable are associated to any active workflows, you can edit those workflows, re-save, then restart the workflow.  From that point forward the workflow will be associated your operator.

Regards,

Craig

[darpan9935 · Accepted solution]

It seems like lot of manual effort. I have tried by creating workflow which can change "created by" and "Modified by" fields. It worked.

[#4]

Hi @darpan9935 ,

you should identify workflows created by "disabled" user and update column ICREATEDBYID
in xtkworkflow table with ID of the user which will remain active.

UPDATE xtkworkflow SET ICREATEDBYID = "ID of active user" WHERE IWORKFLOWID = "Workflow ID";

If you don't have direct access to DB you can do this via workflow as well and update field [@createdBy-id] of the table xtk:workflow with ID of the user which will remain active.

As this not an "usual" operation, please, do update on only one workflow and if it goes well do update for others.

Regards,

Milan

[#5]

Ok we had this exact issue and I did a lot of investigation into this to allow us to disable users from the system (deleting users is another nightmare for another thread). First - Adobe recommend that users never be disabled if they have created workflows. They suggested changing the password to something large and complex and removing client access. This was too messy for me and the security audit guys just didn't buy it. Plus, if you have SSO users, you can't change their passwords as this option is disabled.

I went about it differently and hacked something together we are trialling. This might be completely bad practice but it seems to work for us. I haven't seen any better ways to do this, so happy to hear suggestions.

I found that there is a node in the workflow called [xtk:workflow]/process/@login which is the actual user login used to run the workflow. If this value is empty (ie never run) then this is set to the login value of the first operator to run it. So if you disable that user account, the workflow will no longer run. If you remove the user's rights - the workflow will no longer run.

My solution was to create a special workflow user that had enough rights to run the workflows we needed. You cant login to this user account using the client and the password is something ridiculously hard to guess.

Then you modify the process/login node to use the login for the workflow user. Once this is set, you dont need to change it again. You also have to stop the workflow, change the value then restart the workflow, otherwise the value will revert.

I am aware that this can allow users to have more workflow permissons than they might normally be allowed, but we have a dedicated team that do workflows, so its not usually an issue for us. It might be an issue if you have a more restrictive user permissioning system in place.

Happy to have a discussion on this because this is a major PITA with the user & security system in Campaign.