Before the save or after: PRE and POST workflows

Before you start

• Choose when a workflow runs

A workflow that reacts to a record can run in two places: after the record is saved (POST), or before (PRE). After is the default and the safer choice. Before is for checking a record before saving it.

1. Person clicks Save
2. Before-save workflows
3. Record is saved
4. After-save workflows
5. Run is logged

You choose the timing in the workflow’s settings, under Timing. It appears for the four record triggers (A record is created, A record is updated, Created or updated, A record is deleted). Adhoc and From a webhook workflows have no timing, because no save starts them.

○ ○ ○Beezr

×

After the record is saved (POST) is the usual choice. The save never waits for the workflow.
Before the save, can stop it (PRE) runs first, and can refuse the save.
Order applies inside each timing, so a PRE workflow never competes with a POST one.

What is the difference?

	After the record is saved (POST)	Before the save, can stop it (PRE)
Runs	In the background, once the save has succeeded	While the person waits, before the save
Can stop the save	No	Yes
A failing step	Fails the run. The record stays saved	Refuses the save
If several workflows share the trigger	All run, one after another, by Order. One failing does not stop the next	Run by Order. The first failure stops the rest
Where you see it	As a run in the run debugger	As the message the person gets when it refuses
Good for	Approvals, emails, updating other records, calling other systems	Checks on the values being saved

How does a PRE workflow stop a save?

Two things stop a save. Either a step fails, or a Terminate step ends the workflow as Failed with a message. The save does not happen, and the person gets your message.

A typical check has a Decision that tests the values, and a Terminate on the path that must not save. Layla uses one to refuse a purchase order with no vendor.

1. Decision: Vendor is empty?
2. Yes: Terminate as Failed
3. No: save goes on

Write the message for the person who sees it: “Choose a vendor before saving.” A Terminate step ends the whole workflow, whichever path it is on. Ending as Success also stops the workflow, and lets the save go on.

How do I build a good PRE workflow?

• Keep it short. The person waits while it runs. Use a Decision, a Terminate and little else.
• Choose the trigger by event. Use A record is created, A record is updated or A record is deleted, one workflow for each event you want to check.
• Make the message useful. It is what the person reads when the save is refused.
• Test it by saving a record. Save one that should pass and one that should be refused.
• Leave changes to POST. To update values, use a workflow that runs after the save.
• Deletes. A PRE workflow on A record is deleted runs before the delete and can refuse it. A POST workflow runs after the record has gone, from the values it had.

Which timing should I choose?

• A check that can refuse a save: PRE.
• An approval: POST. An Approval task pauses a workflow for hours or days, and POST lets the record save before the approval begins.
• An email, a notification or a document: POST.
• Changing other records after a save: POST.
• Anything slow, or anything you want to follow in the run debugger: POST.

If you are unsure, start with POST. You can change the timing later in Settings, and the steps stay as they are.

Tip from a Beezr Consultant

When a workflow updates its own record, add a Decision at the top that stops it once the work is done. The update is saved like a person’s, so workflows with a record trigger on the module start again.