Anyone have any other tricks to prevent a workflow...
# suiteflow
e
Anyone have any other tricks to prevent a workflow from initiating besides setting it to Not Initiating and marking it inactive? One would think that would be enough...
k
Just because a workflow isn't initiating doesn't mean it stops running on records that are already in it.
s
if you own it, delete it. can’t run if it doesn’t exist. For workflows from a third party bundle, though, I think Not Initiating is the best you can do.
k
You can make the record exit the workflow as an administrator.
Suspended No new instances of the workflow are created and no existing instances of the workflow are executed. If the workflow includes scheduled workflows, transitions, or actions, none of them will be executed. It is not possible to initiate a suspended workflow from SuiteScript, or by using the Initiate Workflow or Mass Update actions in SuiteFlow. To resume a suspended workflow, change the Release Status of the workflow to a different release status than Suspended. Use when you want a workflow to stop executing but you do not want to delete the workflow.
You probably want a status of "suspended" not "not initiating"
e
They're newly created OPs that are using the workflow. I can't delete it; dependent records. It's becoming frustrating
Yeah, worth trying. One would think being Inactive would be enough though
k
Did you bundle the workflow over?
e
From SB to Prod and then a refresh, yes
k
Is it possible the workflow is tied to two bundles?
Also - is it happening for anyone other than you?
e
Yes, it's happening for two of us who are testing
k
Ooof. Sounds like maybe that's a support ticket to NS then.
Or... do you have a script or another workflow that's potentially that's causing the records to enter the workflow?
e
Hrm, possibly. If that's the case and the script doesn't error I'd be surprised
well, not really, being NS
k
well, if you set it to suspended, and it tries to initiate, you'd likely get the error
c
You can always do a mass update to cancel all existing instances of the workflow
e
Nice, I'll keep that in mind
c
It's often overlooked that workflows take a copy of the backend code when they are instantiated, so you end up with different versions of workflow instances all over the place.
k
It is often worse when you've bundled the same workflow twice - and it has two bundles associated with it. You wind up with duplicate states and then things aren't doing what they should
j
i've added a time in the criteria when schedulling a cutover for a workflow before - i don't recall it giving me too much grief