Legal and accounting
A missing document chased on a precise rhythm, a handover to the right person after a business-hours delay: those are firm rules, rather than universal settings.
Custom automations
Assembling your own rules from actions you already have the right to perform — with tests, versions and a stop button.
7 days, 20 answered calls, no card
The task it takes over
Journeys shipped with a base cover the situations documented by research into that industry. Then there is your own way: that client wants notice the evening before rather than the morning of, that request has to pass an approval, that kind of file has to reach one particular person after a delay.
This add-on lets you assemble those rules yourself. A trigger, conditions, delays, approvals, a version, a test, and a stop. You compose from actions already held: composing grants no new right, and a rule using an action you lack does not publish.
It also opens a door to your own applications: authorising a client app, granting it limited access, receiving signed events with acknowledgement. This is tooling, rather than bespoke development — writing code for one customer and running it at Zenvox is not what gets sold here.
Step by step
- Compose
Blocks you already have the right to use
The editor shows only actions permitted by a base and its add-ons. A missing action appears as an optional add-on genuinely required, rather than as a block failing at runtime.
- Test
A trial ahead of publishing
A rule is tested before publication, and each publication creates a version. You know which one runs, since when, and what it did.
- Run
One run, one key, one log
Every run carries its version and its deduplication key. Steps, waits and retries belong to that same run: they do not multiply it.
- Stop
The stop button belongs to the tool
A rule can be paused. A rule stopped mid-run leaves no half job behind: a technical retry does not repeat the same effect twice.
An add-on, without becoming universal access
Standard connections and journeys needed by a module stay inside that module: this add-on does not become a disguised connection fee. It brings composition, client applications and event delivery.
What it does not open: running arbitrary code at Zenvox, reaching every object because an interface was purchased, and a connector built for a single customer. Where a journey uses a payment, an appointment, a document or a channel, that action must be available in a base or in whichever add-on carries it.
What this changes for your business
Real estate
A maintenance report above a spending cap has to reach an approval. A rule makes that limit automatic rather than dependent on somebody staying alert.
Health and care
Preparation to send according to appointment type, a document requested only in certain cases: one rule per situation, rather than one message for everybody.
Trades and maintenance
Work declined by one crew moving to another, a warranty reminder on a calculated date: the logic of a business, written once.
What it receives
- Events on your files: a request, an appointment, a payment, a message
- Actions already held through a base and its add-ons
- Conditions, delays and approval steps
- Client applications you authorise, with limited access
What it produces
- Published rules, versioned and tested
- Traced runs, with readable diagnostics where something blocks
- Events delivered to your applications, signed and acknowledged
- Controlled replay where a retry is necessary
You publish, you pause, you revoke an application. A rule acquires no right you do not hold.
What is metered, and how
The add-on carries runs per period, delivered events per period, and active automations.
- One run matches one logical trigger and one version: steps do not multiply it
- A branch evaluated without action counts one journey; a technical failure ahead of start counts none
- Deliveries count per event and per confirmed destination, rather than per attempt
- A number of active personal automations, independent of how many runs happen
A run is counted once; calls, messages and documents it performs use their own capacity a single time.
With your applications
A status shown is technical qualification. Standard connections belonging to your modules stay inside those modules.
- HubSpotTo qualifyA rule writing into a customer record assumes a per-account installation and scopes already qualified; the rule does not grant them by itself.HubSpot
- Your own applicationsZenvox native modeA client application you authorise receives limited access and signed events. The receiving endpoint itself is provided by you.My software is not in the list
Questions about this add-on
Does composing a rule grant me new rights?
No. You compose from actions already held through your base and its add-ons: the editor shows only those, and a rule using an action you lack does not publish.
Can I run my own code at Zenvox?
No. The add-on opens neither arbitrary code execution at Zenvox nor a connector built for a single customer. It is tooling: composing rules, authorised client applications, delivery of signed events.
A rule goes wrong — how do I stop it?
The stop button belongs to the tool: a rule can be paused. A rule stopped mid-run leaves no half job behind, and a technical retry does not repeat the same effect twice.
Does connecting a module require this add-on?
No. Standard connections and journeys needed by a module stay inside that module: this add-on does not become a disguised connection fee. It brings composition, client applications and event delivery.
How is a run counted?
One run matches one logical trigger and one version: steps, waits and retries belong to that same run and do not multiply it. A branch evaluated without action counts one journey, a technical failure ahead of start counts none, and deliveries count per event and per confirmed destination rather than per attempt.
Where to next
What exists already with no rule written, or the data feeding your answers.
Custom automations