Hi Community!
We are trying to find an elegant way of preventing the execution of business processes from create, update and delete elements within other business processes.
Think of it as Outlook's 'Stop processing more rules' flag.
We could set a certain flag and add it to the other processes' signal conditions, but this leads to a high coupling of business processes, more complexity, and over the lifetime of a Creatio instance inevitably to errors as everyone needs to know this 'magic' behavior.
Ideally, signals in Creatio would have the option to distinguish between different triggering options, like 'user', 'business process', 'import', 'odata', 'event handler', etc. but unfortunately, this is a missing feature.
Any thoughts would be more than welcome!
Thanks,
Robert
Like
Hello,
At the moment, such functionality is not available in Creatio's OOTB solution for triggering the addition/modification of records.
Indeed, a workaround in this situation can be to create additional columns at the level of the object model that will be filled in depending on which method the record was created/modified (for example, a special column for OData).
We will register this development idea with our R&D team so that they can consider implementing such functionality in future versions of the Creatio product.
Thank you.
Hello Cris,
The approach you previously employed makes sense, but as you’ve noticed, it might not be reliable. One possible reason could be that the 'Modified by' field is being set differently depending on execution context. Additionally, if the Supervisor user manually edits records or if a business process runs under the Supervisor account, it could trigger other processes.
As my colleague mentioned, Creatio doesn’t currently offer a built-in flag to differentiate the source of record modifications. However, a practical workaround is to introduce a custom flag at the object level. For example:
- A boolean field (IsModifiedByBP) that gets set when a business process modifies the record.
A lookup field (ModificationSource) to track whether the change came from a user, a business process, OData, or other integrations.
You can then update your signal conditions to check this flag instead of relying on the 'Modified by' field. This approach ensures flexibility while reducing coupling between processes.