Not sure if this is the issue, but has anyone had ...
# suitescript
r
Not sure if this is the issue, but has anyone had issues with integrations due to record locking workflows? Airbase is pointing to "workflows" as the culprit for integration failures on some POs. Backstory is that they are a startup and developing as they go - we are an early customer of inventory POs. They are using SuiteTalk SOAP.
I've only worked on a PoC with SuiteTalk - I haven't built anything.
e
Do you have any Workflows that lock Purchase Orders? Certainly a locked record could prevent an integration from modifying it.
r
It's NetSuite > Airbase. I don't think POs are getting modified.
Yes, this PO is approved and therefore locked.
e
How is SOAP involved?
r
Airbase is loading POs to create them in Airbase.
It's possible that workflows are not even at issue, I'm just going off what they told me - following up.
e
https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_N2743672.html#bridgehead_4147087484
If you attempt to load a locked record in SOAP web services or SuiteScript, NetSuite throws an error and does not load the record.
šŸ’Æ 1
r
So if that's the case, is there a workaround? It seems like the need to integrate approved POs would be a common use case
e
Some ideas off the top: • Don't lock the record for whatever Role the Integration(s) uses • Push rather than Pull the data out of NetSuite
šŸ‘ 1
m
You can also change the context of the workflow so it does not trigger with SOAP integrations. Just un-select this and the workflow will not trigger for records created/edited via SOAP services
ā˜ļø 1
šŸ‘ 2
r
Excellent, thanks! I can't think of many workflows we would want running on Web Services, so that's helpful.
a
its not the web service that's triggering the lock though is it? some other internal process approves the POs and THAT is when the lock is triggered... once its locked the web service can't load it, so removing the web service context wouldn't help... its possible I've completely misunderstood the use-case /process though. šŸ˜„
r
My understanding is that by removing SOAP Web Services from the context of the workflow, when a SOAP call asks to load a PO, it will not be prevented. Same situation for adding a condition to the Lock Record action.
ā˜ļø 1
m
Yes the workflow or action will not be triggered if the context of the record load/edit is via SOAP services. However if the context is UI then it will be triggered
ā˜ļø 1
a
I'm assuming the locking of the record happens in an approval workflow endstate... once its locked, its locked and the SOAP won't be able to load it... unless you have a WF that's locking in before load if approved = T? in that case then yeah removing the web service context would prevent the lock happening and they could successfully load
e
Locking is not a permanent state. In order for a record to be locked, a Workflow has to lock the record each time the record is loaded
At least, that's my understanding of the Lock Record action; I am not a SuiteFlow expert
a
ahh okay, yeah that makes sense, so the context approach should work then... yeah likewise WFs aren't my forte šŸ˜„
r
what doth lock
m
Yes you are correct @erictgrubaugh so you would remove the SOAP context from the lock record action in the WF state to fix the error
šŸ‘ 1