I have a specific flow that makes a call to ReleaseSalesOrderLinesBySalesOrderHeader after inserting/updating a sales order. I noticed that the newly inserted lines (which should be at open) do not get picked and looking at the associated job I get an error “Not authorized to insert: InventoryCommitments.”. I am able to then pick the lines through the regular head action that should invoke that same logic.
It seems to me that I do not lack the proper security, but another issue is at play in this scenario. Does anyone have any idea what might be going wrong here?
Looking more into it I am guessing there is different security between ReleaseSalesOrderLinesBySalesOrderHeader and OnDemandReleaseSalesOrderLines so I am forced to call OnDemandReleaseSalesOrderLines instead perhaps?
Update does not matter if I call from OnDemandReleaseSalesOrderLines or ReleaseSalesOrderLinesBySalesOrderHeader
@ellen.kaufman those 2 logic blocks are in the same security group so I would also not suspect security is the issue at least from the LB perspective.
Typically when we run into this when logic blocks are called in we’ll say “unexpected” flows its often the initiating logic block’s Security Option which is being restrictive on the table inserts.
Can you confirm whether the Flow you are kicking off uses a Public or a Public Secured value on the Logic Block config? This is on the very first logic block in the call stack
I would also be interested in if you’re tenant is utilizing Org Unit security
I’m not advocating currently for one or the other. This will only aid in identifying what may be happening during execution
Hi Aaron! One of the parent LB’s was public-secured so let me try changing that. The funky thing is this was working for the past two days and just starting hitting this error.
I have updated the LBs to all be public and am still hitting the same issue unfortunately.
I wouldn’t suggest changing the Option just to fix an error. Public Secured is going to be the least restrictive option so if that is for certain the Primary or Initiating Logic Block’s option, we need to look elsewhere for your solution.
1 Like
It does seem like you have a permission gap. Something is requiring table insert specific permission to InventoryCommitments table.
Again, I’m making some assumptions about your true Parent LB. That is presumably in a different security group than ReleaseSalesOrderLinesBySalesOrderHeader is.
Do you know what your permission level is to Logic Blocks in that security group? Read vs Read/Update/Insert/Delete
Ah good point! The parent LB does not match comSales. This is kind of a wild scenario because the trigger logic comes from an itemReceiptBatch table (basically a worktable) that ultimately makes updates to sales orders so security is a little confusing. I will try using comSales to see if this is the gap, but will probably need to investigate what the right group is here.
That would be a valid test but I agree with your last sentence. If that does solve temporarily, a conversation should be had about the correct group for that logic block or a modification to permissions might be enough to get you by.
Definitely needs to be a thought out decision if you need to modify either SG or user permissions.
Unfortunately changing the SG to match did not fix the issue either. I will keep investigating, but do you think this might be a NW bug?
I don’t believe that to be the case. I would be leaning towards unexpected interaction for the setup we just need to identify. The logic blocks you are utilizing perform in their normal use case, so something about the execution is modifying or changing what access level your flow has to the logic being executed when running outside of the Sales Order UI.
How does your flow initiate the updates to the Sales Order? Is it a post-update trigger on a table or through any workflow or background tasks?
These are possible scenarios where the flow’s security auths could be reset and have a new starting point we need to look at
Also double checking on if the environment is using Org Unit Security also
Ah actually Aaron I think you were right and I had to rerun the whole flow instead of my debug LB (different parent). Thank you for helping me resolve that issue! Now I need to fix a timing issue instead 
1 Like
So the security group was the issue for inserting into inventory commitments at least! One problem down! Idk why I was not getting that problem before, maybe the system did not catch it before I re-saved the LB.
Order of operations is very critical for this process.
I’m glad we were able to identify what was preventing your flow from executing the desired flow.
I would once again re-iterate that it is likely not desired to modify your parent LB into the comSales group. However, if your internal discussions deem it to be valid configuration that should get you there.
Good luck on the new error. New errors are always progress.
