We have State A transitioning to State B on AfterSubmit if the context is "USEREVENT". (It goes to State C if the context is "CSV Import" or "User Interface"). Workflow History shows the transition to State B occurred and State A exited. But the weird thing is that the Active Workflow state remains at State A afterward, and State A keeps handling beforeLoad events, while State B never executed any of its actions or transitions, and State B also never shows up in the Workflow History list on the record the workflow is deployed to. Only State A does. It seems like the transition to State B occurred, but it never arrived at State B. This doesn't happen consistently - it only happens once in a while to something like 1% of Journal Entries this user event Workflow is deployed to. I'm not sure how to investigate this deeper and discover why it fails to transition 1% of the time. Any ideas what's going on? Could an Unexpected Error (which doesn't explain anything) be preventing the transition from completing? It doesn't show up in server script logs or Workflow History, but does show up in the Create Revenure Recognition Journal Entries process page.

Is there a transition back to State A from State B under certain conditions? If so, that may have been what happened. The workflow entered State B, met the criteria to transition back to State A and rightfully did so.

@kennkerp Actually no, there's no transition from State B directly back to State A. And if it got there indirectly, wouldn't the Entry and Exit events get logged in the Workflow History for each state it passed through? It's logging these for every use case other than this, and it is also logging that it exited State A. However, it never logs that it entered any other State, let alone State B.

@Aaron McCausland I've seen a slight variation of this same issue where it does transition, but then doesn't actually execute any of the actions on State B (even though the logs say those actions were executed). Have gotten them to investigate and determine it's some sort of unreplicatable network glitch. There's a SuiteAnswers (https://suiteanswers.custhelp.com/app/answers/detail/a_id/95753/kw/95753) and a defect for it (Defect 417298: Transaction Management Problem in Workflow), but they've prioritized it U6 (aka they're never going to actually dig into it/fix it). So I guess all that to say, that yeah, very infrequently (once a year or so), some workflow will just fail to execute some portion of it (in your case the transition) and the logs will show it did do that action, when in reality it didn't. NetSuite is aware of the issue, but doesn't seem to think it's worth fixing, since we can manually fix things. netsuite If you want to tag your support case onto the defect, that would help everyone, but it's been 3+ years with multiple occurrences (and tickets) with no movement, so I'm not holding my breath.

@James Morris Thanks for that tip! That's something we can check for and see if it matches with these failure cases.

I’ve encountered similar when some other process was failing elsewhere (related record also running a WF or some other trigger failing upon the submit) where the WF logs on the o.g. record indicated something was happening but it didn’t actually execute. In my case it was a set value action that logged as executing but the value didn’t set because another script was failing.

@jen I'm hoping it's not that, because that's pretty tricky to track down, but we suspect it might be the case because of the 7,000 Unexpected Errors that occurred on one of our runs of the Create Revenue Recognition Journal Entries process.