🤖 This article was translated by AI.
🚨 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 input, 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 selections 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. |
State change | Triggered when a record reaches the state you have chosen. You can optionally specify the starting state: the automation will only trigger for this specific transition. Note: a record created directly in this state will not trigger anything: a real change is required. |
Scheduling | Triggered automatically, at the frequency you define: daily, weekly, or monthly, at the chosen time. Since no record is at the origin of the trigger, this trigger is combined with "Search records" to target the records to process. |
The 4 Actions
Retrieve a record | Opens a record so that the following actions can use it: either the record that triggered the automation, or a record linked to it: its company, its parent record, its 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 already filled in. |
Search records | Finds all records in a module that match your criteria. You define them as in your usual searches: using 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 record found, 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 state, 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 will 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 record found) and across linked records, to act beyond the record that triggered the process.
Configuring 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 state, or frequency
Add your actions by clicking on the "+": each action opens on add to be configured
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 happens before your eyes, step by step, on the diagram.
Important
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 towards 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 relevant 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 responsible: the person whose action triggered the execution, or "Scheduled".
By selecting an execution, you can view its path directly on the diagram: successful steps in green, failed step in red. In case of failure, the 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 always shows you this. At the maximum, publishing an additional automation is blocked: pause one to activate a new one. You are free to choose which are active, and you can prepare as many as you want in draft.
Monthly Usage
A monthly usage gauge complements this counter: it reflects the volume of actions executed by your automations during the current month, as part of normal use, and resets on the 1st of each month.
Use cases: Build Your First Automations
Important
The states, steps, and types used below are for example purposes: adapt each example with your own values, the construction remains identical.
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 talent pool criteria, built in the filters modal or imported from an existing saved search
On the "For each record" output: Update a record → State: To recontact
→ 30 records or 500: each matching candidate is requalified, one by one, every Monday morning. This is the typical pattern for all bulk processing: it works identically to requalify leads or archive old opportunities.
Use case 2 — The step follows the interview, not the other way around
Your recruiters create the Interview action; the candidate record progresses automatically.
Event on a record: Action type, Creation event
Retrieve a record: the trigger 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 are instantly updated to Client.
State change: Opportunity type, destination state Won
Retrieve a record: the trigger record (the opportunity)
Update a record: the linked Contact → State: Client
Update a record: the linked Company → Type: Client
→ No more "prospect" companies with three invoiced 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 trigger action
Retrieve a record: the parent record (the contact)
Condition: the contact state equals New: only contacts never worked on are affected
Update a record → State: Engaged
→ As soon as the first interaction is recorded on a new contact, their record progresses. A contact already qualified is never touched again: the Condition ensures this.
Important
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 another record than the one in the flow: a linked record.