- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-29-2023 04:10 AM
I enabled the workflow pause plugin in our dev instance, following https://docs.servicenow.com/bundle/tokyo-servicenow-platform/page/administer/workflow-administration/task/activate-workflow-pause-utility.html. I then wrote a business rule to trigger a pause for a scenario. I enabled/committed these changes in our UAT instance and the pause isn't working for non-admin users (but it does in dev). I suspect this is because the "workflow.pause.active" system property is false in UAT and true in dev. The record description says not to edit it manually but I don't know what's controlling it or why UAT is different. Can anyone advise?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2023 01:43 AM
Thanks, that was helpful. I discovered that my script created an entry in the pause table, which triggered that rule to set the property. The problem was that this executed as the person who triggered the business rule and only admins have access to edit system properties. I finally added ACLs to enable the value of that specific property to be changed. I had tried calling a scheduled job (running as system) from the rule instead but it didn't work well because it's an asynchronous process.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-29-2023 05:40 AM
Hi,
I can see this is set to true in a script include 'WorkflowPauseUtil' which is triggered from the BR 'Activate workflow pause'.
This BR is on the table 'Workflow Pause Request'. Based on the BR is a record is created in this table the BR is triggered.
Regards,
Karthik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2023 01:43 AM
Thanks, that was helpful. I discovered that my script created an entry in the pause table, which triggered that rule to set the property. The problem was that this executed as the person who triggered the business rule and only admins have access to edit system properties. I finally added ACLs to enable the value of that specific property to be changed. I had tried calling a scheduled job (running as system) from the rule instead but it didn't work well because it's an asynchronous process.