Accepted AnswerPaul ThompsonOffline0A Notification can run a script when an aux table item has been created or modified. The challenge is the inherent (intentional) latency between the item being committed to the DB and the Notification running.
I think there are too many asynchronous events for this usage case to be viable:
User 1 selects primary item "123" in state "New", does a POST to create an aux item, and delays completing the aux item SUBMIT form. Primary item "123" is “waiting” on the aux item.
User 2 selects primary item "123, does a POST and completes the aux item SUBMIT. The aux item signals the parent primary item to transition to state “B”.
User 1 completes the aux SUBMIT form. The aux item signals parent "123" to transition from "new" to "A" but it can't because it's already been transitioned to "B"
Parent item locked
User does POST via primary item "123" and completes the aux SUBMIT. The primary item is now waiting for the Notification script to run on the aux item and setup the conditions that will cause it to transition
User edits primary item "123". This item is now locked preventing it from being transitioned by the automation.
User does POST via primary item "123" and completes the aux SUBMIT.
User edits the new aux item and corrects the field that determines which state the parent will be transitioned to, just as the Notification runs the script. User clicks OK to update the aux item but by this point the primary item has already been transitioned. The primary item is now in the wrong state based on the updated aux table item.
Accepted Answer0Can't you just have a single relational field on the "main" item referencing the AUX table that is mandatory on a transition and then the selection of the AUX Item drives the next step/state?
How many items do you expect in that AUX table? Is it necessary to have those items submitted on the fly, or is that more like configuration data (mostly static)? What about changes (deletes) in the AUX table?
Accepted Answer0I can't have the Field/value that would drive the decision making on which transition to execute. The problem is how and where do i set this primary item field? for e.g. lets say i create a boolean field in primary item that will help in making decision on which transition to execute but then how would i populate this field and where? Since Post is Async i can't put a script in post-transition also there is no way for me to run a script when an AUX item is actually created in DB. When AUX item is actually getting created that's when i can set this boolean field but SBM do not allow me to hook any script while AUX record is getting created.
Due to some of the items Paul T mentioned i am not considering using Notification. I am trying to come up with a best possible way to achieve this.
Accepted Answer0From what I understand you are trying to drive an action on the primary table with data posted to a second/aux table. In that case you will always run into potential timing/synchronization issues.
I would suggest to add the "driving field" to the primary table (keep that hidden except in the "post" transition where it has to be mandatory) and copy that value into the AUX on post (maybe even have that read-only on the AUX submit), that way everything you need is on the primary table and you can use that to trigger the correct transition/action. No notification required, only actions / pre- / post- scripts.