As we know that if a Workflow is scheduled by someone's user id and if the operator's account get disabled, the workflow will be failed and below type of error message will show.
Now its perfectly fine that if we reschedule that with some other's id which is active, the workflow will again work.
Now the requirement is to get the UserNames who has scheduled a workflow, so that if we can get this before, there will not be a single execution failure, we can schedule the workflow with someone else's id before make that Operator disabled.
Obviously if Adobe can understand that the Operator who scheduled the workflow is no more active now, hence shows error, there must be some table-attribute to get this "Scheduled By" login. Thanks for your help.
You can achieve this from 'Workflow Login' table.
It stores userId of person who has created workflow. Login Id associated with each workflow.
Enrich your workflow with 'workflowLogin' table and update login column corresponding to workflow id.
Seems this may help. Thanks for the answer!
Created by is tagged to that ID who has created the workflow, Modified by is that ID which user has last modification on it. Unfortunately if you schedule a workflow, the last Modified won't change.
No its created by another user. Basically I want to get a list like this for all workflow which are now in "Started" state.
Workflow Internal Name | Workflow Scheduled By
Yes - go to 'all' workflows and add created by ( label ) and last modified by (Label).
Then map it with operator table and check the current account status whether it is active or disabled.
Oh right, of course it does.
Does the same person create the workflow at your organization? If so you could use the created by field
Thanks for your response, checked that as well and it seems the CurrentOperator will show you the login you are currently using and not the login who scheduled the workflow.
So you want to catch workflows that were scheduled by operators that are now disabled? There is a workflow logs table that might be useful for this purpose - xtk:workflowLog, which has a connection to currentOperator.
Also, you could take a slightly different approach around user governance -- if you use SSO and an enterprise ID you can deactivate the user from your Active Directory without needing to remove them from Campaign, so the workflows will continue. You'd likely want to periodically go through and clean it all up, however you would at least not be caught by surprise about workflows failling.