Automate notifications with Zapier
When something happens in Dime.Scheduler, route it somewhere - Slack, email, a CRM. Zapier is the simplest path; Webhook is the lower-level alternative.
Before you start
Zapier is the low-effort path for getting events out of Dime.Scheduler and into something else. Reach for the webhook connector instead when you need full control over the payload, or when the target system is one Zapier does not reach.
Know the shape of what is on offer before you design anything. The connectorConnectorAn integration that links Dime.Scheduler to a back-office system, routing data in and scheduling decisions back out. triggers on appointmentsAppointmentA task scheduled to a resource for a specific period - the scheduled instance you see on the planning board. only: created, updated, removed. If you need to react to a change on a taskTaskA unit of work that belongs to a job. It appears in the open task list until it is scheduled to a resource. or a resourceResourceAn entity that can carry out work - a person, vehicle, tool, or room - that you schedule on the planning board., a trigger will not fire for it.
Actions are much broader. You can create or update appointments, tasks, resources, jobs, categories, time markers, pins, containers, assignmentsAssignmentThe link between an appointment and a resource. An appointment can carry several assignments when more than one resource works on it., notificationsNotificationA message from the back office attached to a task, an appointment or the whole tenant. The notifications component lists them, and a colored vertical bar on the appointment signals their severity., action URLs, captionsCaptionThe label shown for a field or entity in the interface, translatable per language. A tenant that calls jobs "projects" changes the caption, not the data model., filter groups, and filter values, as well as set attributes and delete items.
So the asymmetry to design around is: narrow triggers, wide actions.
1. Get the prerequisites in place
You need a Zapier account, a running Dime.Scheduler instance, and an API key. See prerequisites.
Create the key with a name that says what it is for, so that revoking it later is an obvious decision rather than a risky one. Remember the key is displayed only once at generation.
Build against the sandboxSandboxThe separate Dime.Scheduler environment where upcoming features arrive before the production release. It has its own API host, sandbox.api.dimescheduler.com, so API clients target it explicitly. first. A misconfigured Zap that loops or duplicates is much cheaper to discover there.
2. Create the Zap
Installing walks through finding the connector, creating the Zap, and authenticating.
At authentication you choose the environment, and it belongs to the connection rather than to the Zap, so every Zap built on that connection inherits it. Check you picked the one you meant: pointing a test Zap at production is the mistake that turns a five-minute experiment into a cleanup job.
When you go live, make a second connection for production instead of editing the sandbox one, so the configuration you tested stays intact.
3. Pick the trigger
Choose from triggers: new, updated, or removed appointment. Each delivers the full appointment payload, including job details, resource information, timing, and custom fields, so you rarely need a follow-up lookup to enrich it.
Updated appointment is the one to think hardest about. Any change fires it, including ones you do not care about, so a Zap that notifies on every update gets muted by its recipients within a week. Add a Zapier filter immediately after the trigger to narrow to the changes that matter.
4. Configure the action
Point the action at wherever the event should land: a Slack channel, an email, a CRM record.
If the action writes back into Dime.Scheduler, get source appSource appAn identifier Dime.Scheduler attaches to data so it can route a change back to the correct back-office system. and source typeSource typeAn identifier that, together with the source app, tells Dime.Scheduler which back-office table a record belongs to. right. They are what identify where a record came from and how it routes, and they are the usual cause of records that are created successfully but never appear where expected. See actions.
5. Test before enabling
Run the Zap against sample data and confirm both ends: the trigger fires when you expect, and the action produces what you want at the far end.
Then enable it.
Verify
Do the round trip with a real appointment rather than Zapier's sample payload. Sample data has every field populated; real data often does not, and a Zap that depends on an empty optional field fails only in production.
If the Zap writes back into Dime.Scheduler, check transactions to confirm what actually arrived.
Related
- Set up a webhook connector for full control over the payload.
- Zapier troubleshooting when a Zap does not fire.