Automation Architect
Design safe automations across records and related objects.
Open interactive lesson and quizWhat you will learn
- Translate a process into trigger, criteria and action
- Use relationship paths safely
- Test and diagnose every run
Repetitive follow-ups and status updates are being missed. You will automate them while protecting related records from unintended changes.
Lesson 1
Trigger, criteria, action
Every automation needs a precise event, optional conditions and a deterministic action. Start with the smallest rule that delivers a clear business outcome.
Start by writing the requirement as a sentence: when a contact is created with a qualified status, create a follow-up task for the record owner. The trigger identifies the event, conditions narrow which records qualify, and the action defines the result. Avoid one rule that tries to perform unrelated processes.
Build the rule with a specific object and event, then prepare one record that should match and one that should not. Check task ownership and due details after testing. Creating a rule in the builder is not proof that it has run; confirm that it is enabled and inspect its execution history.
Lesson 2
Related-record automation
When a contact or deal changes, update only a valid related record reached through a configured lookup. This prevents broad, unintended updates.
Use a saved relationship to identify the target of an update. For example, a change to a contact may need to update the linked company. The lookup must point to a valid record in the same BU; a similar company name is not enough. Decide what should happen when the relationship is blank before enabling the rule.
Test the populated-lookup and missing-lookup cases separately. Change only the target field required by the process, and check whether another automation watches that field. Two rules updating each other can create repeated work. Keep the conditions narrow and verify the final state of both records.
Lesson 3
Operate, test and observe
Test with a representative record, inspect run history and keep failed runs visible. Disable a rule before editing a live business process.
Use a Trial org and representative records before enabling a process for daily operations. Test the intended case, a nonmatching case and incomplete input. Inspect the execution result and the actual task, notification or related record. A successful request to save a rule is different from a successful action execution.
If a rule behaves incorrectly, disable it before changing records to repair the result. Review the failed run, correct the data or configuration, and retry only after checking whether part of the action already occurred. For outbound webhooks, the receiving system should recognise a stable event identifier so retries can be handled safely.
Practice · Automate a related-record update
- Create a field-change automation
- Select a valid related object and field
- Change a Trial record and inspect the run result