When using suitescript's Task API to launch a Workflow, should that workflow be User Event triggered, or Scheduled? And should it be Status = Released, Testing, Not Initiating, or what?

AI generated answer (using internal Slack threads):

When using SuiteScript's Task API to launch a Workflow, the workflow does not necessarily need to be User Event triggered or Scheduled. It depends on the specific use case and requirements. However, it's important to note that User Event scripts are triggered by user actions, while Scheduled scripts are designed to run on a schedule. As for the status of the workflow, it should be set to "Released" if you want the workflow to run for all users. If you set the status to "Testing", the workflow instance will only initiate for the owner of the workflow. Any user who accesses the record will see the changes made by the workflow. Workflow actions execute for the user even though the user did not initiate the workflow instance. In "Not Initiating" status, new instances of the workflow do not initiate but already running instances of the workflow will continue to run. The workflow still appears on the Workflow list page. "Suspended" status means 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. Please note that setting a workflow status to "Suspended" or "Not Initiating" prevents initiation of new records into the workflow, but does not cancel any record instances that are already in the workflow. ****** Disclaimer: This response was generated by an artificial intelligence assistant based on previous conversations from multiple Slack channels, and may contain inaccuracies or mistakes. ******

it will not scheduled. status released

It seems to work only when triggered by script (which is what I want), if I set the workflow to Released status as a User Event - before submit, but un-check the On Create checkbox and the On View/Update checkbox.

can you share your complete scenario plz

My goal is to change a custom field on the Purchase Order lines, where a native field meets certain criteria. This workflow was originally created to run on a schedule, so it was using a saved search condition to only initiate on Purchase Orders that needed it. This search condition was still in place when I was asked to make it run immediately instead of on a schedule, and the search cost 3 more seconds of runtime than Purchase Orders already took to save and load. So I tried having a UE script run the workflow asynchronously instead, and I got that working, but this creates a race condition with other afterSubmit scripts that modify the record and re-save it, so it would randomly fail. In the end, I removed the saved search condition and relied only on conditions on the record in memory, having it run on beforeSubmit instead, and this costs only 1 second of runtime without the saved search having to run first. So that's how I'm going to do it instead.

Your approach makes sense and is a much cleaner solution overall. Removing the saved search condition and relying on in-memory checks significantly improves performance, and moving the logic to beforeSubmit avoids the race condition you were seeing with asynchronous execution and competing afterSubmit scripts. This way, the custom line field is updated reliably before the record is saved, without needing additional triggers or re-saves. It’s a more efficient and deterministic design, and given the reduced runtime impact, it sounds like the right direction to move forward with.