For me, triggers are something database sided and used to insert/update/delete records in other tables to keep them up-to-date based on my action inside the GUI. Process flows are more of a workflow for an user inside the End product. For example, the user inserts a new record and then a screen should pop-up where he sees data that has been created for him (via trigger). 

It could be that an user creates a Transport and then automatically Shipments are added to that transport. The trigger makes sure the Shipments are connected to the Transport, then the Process Flow will ensure a screen opens where the user can see all the Shipments attached. And as added bonus, maybe a message saying how many Shipments are attached.

In short:

• Triggers are for database sided mutations
• Process flow are for workflow/processes inside the End product

Of course triggers and Process flows can overlap in certain places, but in the majority of cases the above applies.

Kind regards,
Mark Jongeling

Hello Roy,

Triggers are not old and will not be deprecated, there are valid scenarios for both process flows and triggers. Process flows and triggers are actually quite different things, but they do have an area of overlap.

Advantages of triggers

• They will always fire and therefore give a higher degree of certainty. If you perform an insert/update/delete statement from another application, directly on the database, a process flow won’t fire, but a trigger will. Furthermore, if an error occurs inbetween two process actions, it’s possible that the next process action will not fire either. With triggers, the original action and the trigger are more of an atomic thing. In general, both will execute or neither will.

Advantages of process flows

• You can do much more than just SQL statements after an add/edit/delete process action. You could very easily call a webservice, print a report, send an email, write a file, without having to compromise the security settings of the database. You can also control the user interface from a process flow, for instance by opening a document or navigating to a detail tab.
• There is room for user interaction, e.g. users can fill out some fields for a record or a task if necessary.
• When performing an insert, update, delete, task, etc. from a process action, things like authorization and business logic will be applied as well. If you use default and layout procedures to guarantee the integrity of your data, then these will be applied automatically and you don’t have to worry about it or duplicate your business rules in the trigger logic.
• You can get a much clearer separation of logic. If you have a situation where, based on some condition, you want to do one action or another action, then the condition can be placed in a process procedure and both actions could be their own process actions. Over time this will be easier to manage. It is also easier understand at a glance and explain to others when looking at the process flow diagram.
• The fact that triggers always fire can also make them very messy. You have to be aware of the concequences of insert/update/delete statements at a very deep level. If you insert a record in table2 from the trigger of table1 and table2 has a trigger as well, then this will cause the trigger of table2 to fire as well, and so on. It’s even possible to get an infinite loop in this way which will eventually produce an error. This can be avoided by checking the nest level, but it can be difficult to keep a clear picture in your head of what the concequences will be.

Hope this helps.