Case study · CRM and integration consulting
An integration engine Motii's team configures for each client
Motii Wizard is Motii's integration engine for two-way integrations between business systems. Its first connects Simpro and Pipedrive, with more integrations in development.
- Pipedrive
- Simpro
- TypeScript
- Node.js
- OpenAPI
- Zod
✓ Verified Review“Working with National Digital, we looked beyond what we needed today and thought about where we wanted to take Motii Wizard. The result is the next generation of Wizard: an integration engine our team can configure for each client, engineered to be reliable and built to grow with our clients’ needs. National Digital brought the technical discipline to make that possible, and we’re really pleased with what we’ve achieved together.”
Frederic Schnell Managing Director at Motii
1,400+
automated tests in the engine
Twice
times we have built this engine
Both ways
direction of synchronisation
AU
where it is hosted, in Australia
At a glance
- Industry
- CRM and integration consulting
- Engagement type
- Product engineering
- First release
- 2026
- Team
- National Digital engineering team
About the client
Motii is a CRM and integration consultancy and four-time winner of Pipedrive’s Partner of the Year award for Australia and New Zealand. From CRM implementation and integrations to automation, training and ongoing support, Motii builds technology around how each business works. Motii Wizard is Motii’s integration engine for connecting the systems a business runs on, starting with Pipedrive and Simpro, so information flows between sales, operations and finance with less manual data entry.
The challenge
Motii's customers each run a different combination of business systems, and each wants the handful of automations that matter to them. Building those one customer at a time makes every change a deployment, and handing customers a general-purpose scripting surface means support staff end up debugging customer scripts in production.
What we built
National Digital built a rule engine that Motii's team configures for each client. Reusable rule packs install the common automations for a new customer, and each handler declares a typed configuration schema that tells the administration interface how to render its settings.
- Typed rule configuration validated against a schema, so Motii's team can change a setting without waiting for a release
- A closed, registered set of handlers, where adding a new action means writing and testing the handler first
- Reusable rule packs that install a customer's common automations with per-rule configuration overrides
- Field aliases, so handlers refer to a friendly name while the platform sees its own custom-field key
- Entity mappings written before any write-back, which makes a retry safe to run twice
- A self-trigger guard that recognises the system's own writes returning as webhooks
- An administration console with event detail, execution logs, rule descriptions in plain English and an entity timeline
The stack
The engine runs as a TypeScript API and worker behind a queue. Webhooks are verified on receipt and processed asynchronously, and entity mappings are written before any write-back so retries are safe. A self-trigger guard detects the system's own writes when they return, and an administration console shows every event and rule execution with its outcome and reason.
Admin consolePacks, typed config, event detail
Rule engineRules as data, handlers as code
Platform clientsPipedrive, Simpro and more; verified webhooks, mapped fields
Entity mappingsCross-system links, safe retries
Queue & logsAsync processing, execution reasons
The outcome
Motii's own team installs a rule pack for a new customer and fills in typed configuration fields without briefing a developer. When something does not happen, the execution log names the rule, the event and the reason it was skipped or failed, so support staff can answer the first question in a support call from the console. The engine carries more than 1,400 automated tests, and each handler is tested before a rule can use it.
Where it went next
The pattern generalises past this engagement. The parts that are expensive to get right - the configuration schema, the field resolution and the loop prevention - are the parts worth reusing, and the handler set is deliberately small and grows with the customers it serves. Where a client's engineers already work in a separate automation tool, the rule layer can hand off to that tool.
This case study describes a real engagement. Figures about the codebase are counted from the National Digital repositories. Adoption figures are Motii's commercial information and are not published here.
Key Takeaways
What makes a configurable automation layer safe to hand over
- Rules are stored as data, and every action they take is a handler tested in code.Critical
A rule record names the platform, the object type, the trigger conditions and a configuration object. Motii's staff decide which rules fire and under what conditions, and the handler code fixes what each action can do. A rule cannot run logic outside the registered set.
- Typed configuration schemas let a non-engineer configure a rule.Important
Each handler declares the fields it takes, with a type, a label and whether it is required. The interface renders a pipeline picker or a stage picker from that declaration, so the person configuring a rule chooses a pipeline by name and does not need to paste an identifier.
- Write the cross-system link before the write-back, and a retry becomes safe.Important
Entity mappings record that a deal corresponds to a quote before anything is written to the other platform. Running the same event twice then finds the existing link and does not create a second record, so the queue can replay an event safely.
- A two-way sync has to recognise its own writes coming back.Important
Every write the engine makes produces a webhook from the platform it wrote to. A self-trigger guard matches those against what was just written and skips them, which stops each write from triggering another write in the opposite direction.
- Every execution should log its outcome and its reason.Helpful
Every event and every rule execution is stored with its outcome and the reason. When an automation does not fire, the administration console shows why, and the support conversation starts from the recorded outcome.
A client can safely configure automation when every action a rule can take is fixed and tested in code. Typed settings and a logged reason for each execution keep it manageable.
Questions decision-makers ask about this build
Why build a rule engine instead of using an off-the-shelf automation tool?
The automations live inside the product the client's customers already use, and the same few rules recur across many of them. An external tool is the better answer when a technical team is happy working in a separate canvas and the data is allowed to leave the product. Where business users need to configure well-understood actions in place, a rule layer with reusable packs costs less to maintain and support.
How much can the client change without a developer?
The client's team can choose which rules are installed, set the conditions that trigger each one and change any setting a rule exposes. The administration console renders those settings from each handler's typed schema, so a change takes effect without a release. A new kind of action needs a developer, who writes the handler and its tests before any rule can use it.
What happens when a sync fails halfway?
The event stays in the queue with its state recorded, and a sweeper re-queues events that stopped moving. Retries are safe because the cross-system link is written before the write-back, so processing the same event again updates the record it already created and does not add a duplicate.
How do you stop two systems from triggering each other in a loop?
The engine records what it wrote and matches incoming webhooks against it, so a change it made itself is recognised and skipped. Identical events arriving twice within a short window are also de-duplicated. The engine needs both checks, because each write to one platform returns as a webhook that could otherwise trigger a write back to the first.
Does any of this transfer to a different pair of systems?
The engine, the rule model, the packs, the field resolution and the loop prevention transfer. The platform clients and the handlers are specific to the systems involved, and that is the work in adding a new one. Starting with the two or three automations a client needs now is the cheaper path, because the configuration schema is hard to guess before real use.
More of our work
Integrations
Gratofy: A Corporate Gifting Marketplace
Booking platforms
Luxico: A Property Management Platform
Custom software
MyStrengths: Student Assessment Platform
What's next
Automations your team can change?
Motii's team configures Motii Wizard for each client from an administration console. If your product needs automations that non-engineers can configure, see how we approach AI and automation and system integration, part of our wider custom software development work.