Build automation packs for your customers

An automation pack is a named set of automations your customers add in one go from their own automation gallery (Automations → New automation → Automation packs). DMLY ships eight packs. On Automation packs in your Reseller Dashboard you build your own: pick automations from DMLY’s library, or copy one you already built and tested for a customer, then publish the pack to every customer you have. Your customers add a pack to one channel at a time, and everything in it arrives paused. They check it and switch it on themselves. What that looks like on their side is in Add an automation pack.

​

Create a pack

​

Add automations

Under each pack are two buttons: Add from the library and Copy from a sub-account. They disappear once the pack is full.

​

From the library

Add from the library lists DMLY’s flow-builder automations. Quick automations aren’t offered, because a pack can only install a flow. Search by name, description or industry. Each one shows what starts it, its industry and the channels it runs on, and two labels to watch for: A.I. (it has an A.I. step) and Answers every message. Select Add; anything already in the pack reads In pack. DMLY ticks the obvious prerequisites for you from the steps the automation uses: a booking step needs a service and working hours, a payment step needs a payment method, a WhatsApp template step needs an approved template. It does the same for an automation you copy. Check them under Edit.

​

The rules a pack keeps

These are refusals with a reason, not warnings, because a pack that breaks one installs fine and then half of it can never be switched on:

• At most nine automations. A pack holds at most 9 automations. Split it into two packs, or remove one first. The pack shows <n> of 9 automations so you can see how close you are.
• One automation that answers everything. On any channel only one automation answers a given message, so a second catch-all would install and then refuse to switch on. An automation that answers every message or every comment (any match, or no keywords) is labelled Answers every message, and a pack takes one. Give the other one keywords, or pick a different automation.
• Each library automation once. That automation is already in this pack.
• Every name different. No two automations in a pack may share a name, ignoring capitals, whether you add one from the library, copy one or rename one: An automation called “<name>” is already in this pack. Give one of them a different name. Two of one name can’t be told apart in the gallery or the list, and the automatic install for new customers leaves out anything whose name is already on the channel.

​

Copy an automation from a sub-account

The best pack is often one you have already proved: a flow you built for one customer, tested, and watched work. Copy from a sub-account turns it into a pack automation every customer can add. A copy is a snapshot. Changing the flow in the customer’s workspace afterwards doesn’t change the pack; to update it, remove the automation from the pack and copy it again. A copied automation is offered only on the channel type it was built on: one built on WhatsApp installs only on WhatsApp.

​

What is cleared, and why

A flow built in one customer’s workspace is full of things that only mean something there: the id of their WhatsApp template, their pipeline stage, their teammate. It can also point at accounts that are yours: your webhook endpoint, your spreadsheet, your phone number. Copied as they are, the first kind would be wrong for every other customer, and the second would quietly send every customer’s data to you. So nothing of either kind survives the copy. Each one is left blank: Most of these are required: each customer fills them in for their own business before the automation can go live. A few are optional and are simply cleared (a webhook with no headers is still a valid webhook). DMLY deliberately doesn’t try to match by name (“Main pipeline / Won” in one workspace to a stage in another): a wrong match is invisible, and a blank is not. A step that acts on one particular appointment, invoice or subscription is cleared too, back to the one the automation is running for ({{appointment.id}} and the like), so customers have nothing to fill in there. What stays: every message, button and question; tags, which are names and create themselves in each workspace; and {{variables}}, which are filled in at run time in whichever workspace runs the flow. A customer-side setting written as a variable is kept for the same reason. Anything that points at your accounts is cleared whatever it holds.

​

What can’t be copied

This one can't go into a pack: is followed by one or more of:

• The automation isn’t published: Publish this automation first. Only a published automation can be copied into a pack.
• It has more than 200 steps.
• It uses a step that can’t go into a pack yet: the Slack and HubSpot steps, whose settings name channels and pipelines in your own Slack and HubSpot, and the older Book meeting step (superseded by Appointments). “<step>” steps cannot go into a pack yet. Remove that step, or use a built-in automation instead.
• Its trigger has no event, so it would install and never start, or starts on an event that doesn’t exist.
• A connection points at a step that isn’t in the flow.
• A link a customer is sent (a CTA URL button, an image, video, audio or file, a header) isn’t a web address, or points at localhost or a private network address.
• It breaks one of the rules a pack keeps, including an automation of the same name already in the pack.

​

Edit an automation in the pack

Each automation’s row shows its labels (Copied, Optional, A.I., Answers every message), what starts it, the channels it runs on, what it needs before it can go live and, for a copy, what each customer fills in. Use the arrows to move it up or down: the order here is the order customers read in the preview. Edit opens:

• Name your customers see: a new name, different from every other name in the pack. For a library automation, leave it blank to keep the original; a renamed one shows Renamed from “<original>” and installs under the new name. A copy’s name is already in the field and is required, since a copy has no other name to fall back on: saving it blank is refused with A copied automation needs a name.
• Description: what customers read under the name.
• Importance: Core: switch this on first, or Optional: worth having, not day one. Customers see an Optional label on the second kind.
• Can’t go live until the customer has…: a service or product to sell, your working hours, your booking page set up, a payment method connected, at least one contact, an approved WhatsApp template. Each one ticked must be true in the customer’s workspace before the automation will switch on; until then they see Needs setup and are told what is missing.

Remove takes an automation out of the pack. Customers who already added it keep their copy. If it was the last one in a published pack, the pack goes back to a draft. A library automation that DMLY has since retired is marked No longer in the library. Customers don’t see it and installs skip it; remove it when you next edit the pack.

​

Publish a pack

Select Edit on the pack and set Status: Then Save pack. A pack needs at least one automation to be published: Add at least one automation before publishing this pack. Once customers start adding it, the pack’s summary line counts them: added by <n> customers means that many customer workspaces have at least one automation from it. Delete removes the pack and its list of automations from your dashboard and from every customer’s gallery. It can’t be undone; archive it instead if you might want it back. Automations customers already added stay exactly as they are.

​

Put your packs in order

Use the arrows beside each pack’s Edit button to move it up or down your list. The order is the order customers see your packs in their gallery (yours always come before DMLY’s), and it decides which pack a new customer is given when two of yours are tied to the same business type: the higher one.

​

Give a pack to new customers

Give it to new customers who are a… ties a pack to the business type a customer picks when they sign up: Salon, spa or barbershop, Clinic or wellness, Retail or e-commerce, Restaurant or cafe, Real estate, Agency or consultancy, Education or coaching or Something else. When a new customer of that type connects their first messaging channel, they are given your pack, paused, instead of DMLY’s. The pack must be Published. It happens once per workspace, so changing the setting later doesn’t touch customers who have already been set up. The automatic install leaves out anything the customer already has under the same name. If more than one of your published packs has the same business type, the higher one in your list is used. A customer whose business type has no pack of yours depends on Show customers only your packs: So with the switch on, a published pack tied to Something else is your catch-all for every business type you haven’t built a pack for.

​

Show customers only your packs

The switch at the top of the page decides whether DMLY’s packs appear beside yours:

• Off (the default): customers see your published packs first, then DMLY’s.
• On: customers see only yours, and a new customer is only ever given one of yours (see Give a pack to new customers).

The switch takes effect once you have published at least one pack of your own. Until then DMLY’s packs keep showing, and keep being given to new customers, so switching it on early never leaves your customers with an empty gallery. Customers never see who made a pack: there is no owner name on it, yours or DMLY’s.

​

Who on your team can do this

Three permissions under Automation packs when you build a role on Team: Copying is its own permission for the same reason opening a customer’s workspace is: it reads that customer’s flow, every message in it included. Grant it to the people who build flows for your customers, not to everyone who manages packs.

​

Do it over the API

Everything on this page is also on the Agency API, under /packs. Copying from a sub-account over the API needs a key that was generated with Copy automations out of sub-accounts into packs ticked, and only someone who holds Copy automations from sub-accounts into packs on your team can tick it. Any other agency key can build packs from the library but not read your customers’ automations.

​

What to do next