Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

Understanding Workflows Set Values

raprohaska
Kilo Guru

I've been working in ServiceNow for a couple years now but my teammates typically dealt with workflow creation. They practice some implementations that I've never understood and would like to clarify. When setting values, many times they will use a timer before the set values activity. I have been building out a new workflow and using set values within it. If the record had been updated thus triggering the next activity in the workflow, the set value will be saved as expected. In my case though, when an approval is given (thus the update is to the related requested approval record) and I have a Set Values activity there after... the update of value is not committed.

Why is this? Is there a way to invoke a save from the Set Values activity that I'm missing? And why does adding the timer do anything to help out the situation. I don't want to add these timers to my workflow and figure there must be another way.

Thanks,

11 REPLIES 11

The activity is very basic, just sets state. I would agree that it should work without the current.update()... yet when that activity is not in place, the state value does not change.


find_real_file.png



I took out the update activities and ran this example:
find_real_file.png


**Noitice that the state is Authorize, yet the workflow has gone through both a set state = schedule and set state = implement activities:



find_real_file.png



When I include the current.update scripts, the record progresses through the states as expected.


Looks like something is wrong with your workflow.


When it is in authorized state, it should wait till Change is approved.


I dont see the approval - User to Approval - Group activity.



Instead you have an 'If approved' activity. Do you need some correction their?


Can you post the whole workflow?



Please mark this response as correct or helpful if it assisted you with your question.

Unfortunately my priorities have changed. When I find time, I'll setup a simple workflow where I can duplicate the issue. Our approval process is overly complicated and fairly configurable. The approval activities are actually encapsulated in a sub flow. The sub flow returns one of 3 values, Approved, No Approval Needed, or Rejected.



Our issue may not stem from just activities after approvals as we have faced similar issues in other places, this is just the example I have been working on now.



Thanks for your time, I'll post more as soon as I can. At least I have a work around for the time being.


I'm experiencing the same problem.   I may have found a cause in my case - write ACLs on the same form that the workflow is running (check properties of workflow to determine the form).



Per http://wiki.servicenow.com/index.php?title=Workflow_Concepts#gsc.tab=0


"when a user approves a request, the workflow uses the credentials of the approving user"



which means the Set Values activity will use the permissions of the previous approver to try to write to the fields.   If that approver doesn't have write access to the field(s) being set in the set values, they won't be changed.



In our case, we had an ACL that gave write access to approvers, but only if their approval was in a 'requested' state.   Of course, by the time the set values activity was run, the approval state had been changed to approved (that's how the workflow was able to move on to the set values activity), so the ACL failed.


I haven't looked into this any further since I posted but as I'm thinking about it, at least in my situation where the set values happens after an approval, the approval is triggering this workflow through a workflow event. The actual "save" that was performed was on the approval table, not the targeted task. I'm wondering if that is why values aren't set.



I'm totally not sure on this but if I can find some time I'll look further and post back.