Back to daily archive
Development/

Security by design: Trigger discipline

JSBC Labs retrospective note4 min read

Why this deserves attention

Triggers should coordinate record-change behaviour without becoming a hidden application framework. The important work is to turn the assumption into a visible decision.

Multiple unmanaged triggers create uncertain execution order, recursion and changes that are difficult to reason about. On 10 September 2025, this archive entry records the principle as a practical design concern rather than a product announcement.

Treat trust as a requirement

Look at trigger discipline through how access, data exposure and accountability shape the implementation. The objective is not to introduce more process; it is to expose the few decisions that determine reliability, ownership and future change.

Use one controlled entry point per object, separate orchestration from business logic and make recursion protection intentional. Record the decision close to the solution so that delivery, support and future architecture reviews work from the same intent.

What good looks like

Record automation remains predictable as the org and development team grow. The team can describe the expected behaviour, the owner, the evidence of success and the response when reality differs from the design.

A useful next step is to review one live implementation against this principle, identify the largest unowned assumption and turn it into a bounded improvement with a measurable outcome.