🤖 This article was translated by AI.
🚨 Please note
This feature is available for customers subscribed to the Advanced, Enterprise, or Business plans.
If you want to learn more about these plans, you can visit our website and contact us at [email protected] to discuss with our teams.
As soon as an event occurs in Boond, the actions you have defined are executed automatically. Less manual entry, always up-to-date data, with no technical skills required.
Understanding an Automation: Triggers and Actions
An automation links a trigger (the event that starts it) and one or more actions (what Boond executes next), which you visually assemble in an editor. All choices are made from lists, with the states, steps, and labels from your environment: no technical input is needed.
Currently, automations cover 12 modules: Candidates, Resources, Contacts, Companies, Opportunities, Positionings, Projects, Deliveries, Products, Purchases, Supplier invoices, and Actions.
The 3 Triggers
Event on a record | Triggered when a record is created, updated, or deleted in the module of your choice. You check the event(s) you are interested in: Creation, Update, Deletion. |
Status change | Triggered when a record reaches the status you have chosen. You can optionally specify the starting status: the automation will only trigger for this specific transition. Note: a record created directly in this status will not trigger anything: a real change is required. |
Scheduling | Triggers automatically, at the frequency you define: every day, every week, or every month, at your chosen time. Since no record triggers the event, this trigger is combined with "Search records" to target the records to process. |
The 4 Actions
Retrieve a record | Opens a record so that subsequent actions can use it: either the record that triggered the automation or a related record: its company, parent record, manager, etc. You choose from a list; only records actually accessible at this step are offered, and if there is only one possible choice, it is pre-filled. |
Search records | Finds all records in a module that match your criteria. You define them as in your usual searches: with the same filters window, or by reusing a saved search. You cannot validate a search with no criteria: you will never process an entire module by mistake. Actions placed on the "For each record" output are executed on each found record, one by one; those placed on "At the end" are executed only once, when everything is finished. |
Update a record | Modifies one or more fields of the selected record. You add a line for each field to modify, and the input adapts: a list of values for a status, a calendar for a date, Yes / No for a checkbox. The values offered are always those from your environment. |
Condition | A decision point with two outputs, Yes and No. You choose a field, a comparison (equals, contains, is greater than, is empty, etc.), and a value: the next steps only execute on the Yes branch if the record meets the criteria. An optional advanced mode allows expert users to write their own expressions. |
The power comes from the combination: a trigger followed by chained actions, including in bulk (a search applies the sequence to each found record) and across related records, to act beyond the record that triggered the automation.
Configure an Automation
Go to Administration → Customize
Click on Automations
Click the + button
Name your automation (click on the title "My automation") and choose your trigger: its panel opens to define the record type and, depending on the trigger, the events, destination status, or frequency
Add your actions by clicking on the "+": each action opens for configuration as you add it
Save
Publish: your automation is active and will trigger as soon as the event occurs
Test before publishing
The Test button temporarily publishes your automation for validation. Then perform the action expected by the trigger: execution unfolds before your eyes, step by step, on the diagram.
Good to know
Automations actually modify your data. For your tests, use test records rather than production records.
Publish, Pause
A published automation is active: it triggers on every corresponding event. You can pause it at any time: it is kept with all its configuration and history, and will not trigger again until reactivated. Drafts and paused automations do not count toward your quota.
Execution Rights
Each automation runs with the rights of the person who created it: it will never be able to view or modify data beyond what its creator can do. If rights are missing on a record, the execution fails, visible in the monitoring.
Monitor Executions
Each automation has an Executions tab that logs all its triggers, from most recent to oldest: status (Success or Failure), start date, end date, duration, and owner: the person whose action triggered the execution, or "Scheduled".
By selecting an execution, you see its path directly on the diagram: successful steps in green, failed step in red. In case of failure, details automatically open on the relevant step: you can read the clear reason and the affected record. You always know what was done, on which records, and why.
Quotas and Usage
Active Automations
The number of active automations (published and not paused) depends on your plan. A counter at the top of the list shows you this at all times. At the maximum, publishing an additional automation is blocked: pause one to activate a new one. You freely choose which are active, and you can prepare as many drafts as you want.
Monthly Usage
A monthly usage gauge complements this counter: it reflects the volume of actions executed by your automations during the current month, under normal usage, and resets on the 1st of each month.
Use Cases: Build Your First Automations
Good to know
The statuses, steps, and types used below are examples: adapt each example with your own values, the structure remains the same.
Use Case 1 — Your dormant candidates wake up automatically
Each week, your talent pool is automatically requalified: no more forgotten profiles.
Scheduling: every week, Monday at 8:00 a.m.
Search records: Candidates module, your pool criteria, built in the filters modal or imported from an existing saved search
On the "For each record" output: Update a record → Status: To be contacted again
→ 30 records or 500: each matching candidate is requalified, one by one, every Monday morning. This is the standard pattern for all bulk processing: it works the same for requalifying leads or archiving old opportunities.
Use Case 2 — The step follows the interview, not the other way around
Your recruiters create the Interview action; the candidate record moves forward automatically.
Event on a record: Action type, Creation event
Retrieve a record: the triggering record (the created action)
Condition: the action type equals Interview: a call or email does not trigger anything
Retrieve a record: the parent record (the candidate)
Update a record → Step: the corresponding step of your process
→ Your pipeline reflects the real pace of interviews, with no re-entry.
Use Case 3 — A won opportunity, an up-to-date CRM
The deal is signed: the contact and company instantly become Clients.
Status change: Opportunity type, destination status Won
Retrieve a record: the triggering record (the opportunity)
Update a record: the linked Contact → Status: Client
Update a record: the linked Company → Type: Client
→ No more "prospect" companies with three billed projects.
Use Case 4 — A first action qualifies your contact
Your prospecting lists show "New" for contacts already called three times.
Event on a record: Action type, Creation event
Retrieve a record: the triggering action
Retrieve a record: the parent record (the contact)
Condition: the contact status equals New: only contacts never worked on are affected
Update a record → Status: Engaged
→ As soon as the first interaction is recorded on a new contact, their record advances. An already qualified contact is never touched again: the Condition ensures this.
Good to know
After a Search records, the record is already available on the "For each record" output: no need to add a Retrieve step. Retrieve is used to load a different record from the flow: a related record.