> ## Documentation Index > Fetch the complete documentation index at: https://docs.dmly.io/llms.txt > Use this file to discover all available pages before exploring further. # Build automation packs for your customers > Put together sets of automations your customers add in one go, from DMLY's library or from flows you built for a customer, and choose who starts with which. 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](/automation/automation-packs). Nothing you do here reaches into a customer's workspace. Adding a pack copies its automations into the customer's own list. Editing, unpublishing or deleting the pack later changes what the next customer gets, never what an earlier one already added. ## Create a pack In the Reseller Dashboard sidebar, under **Configuration**, select **Automation packs**, then **New pack**. * **Name**: what customers see on the card, up to 120 characters. * **Industry**: shown on the card beside the automation count. **Any industry** shows none. * **What it does, in one line**: the summary under the name, up to 300 characters. * **Give it to new customers who are a…**: see [Give a pack to new customers](#give-a-pack-to-new-customers). Leave it on **Nobody automatically** for a pack customers only find in the gallery. Select **Create pack**. A new pack is a **Draft**: no customer can see it until you [publish](#publish-a-pack) it. ## 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](#edit-an-automation-in-the-pack). ### 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 ` 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 “” 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. Select **Copy from a sub-account**, then the **Sub-account** and the **Automation**. Only sub-accounts with a published flow automation are listed, and only their published flow automations. What is copied is the **published** version, not a draft someone is still editing. Before anything is saved, DMLY checks it and says either that it can be copied, and which channel it is limited to, or `This one can't go into a pack:` and why. It also lists what each customer will fill in, or says `Nothing needs clearing; it installs as it is.` Select **Copy into pack**. The automation joins the pack marked **Copied**, and its row lists **Each customer fills in:** with every step that was cleared. 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: | Cleared because it belonged to that customer | Cleared because it points at your accounts | | - | - | | The segment, stages, lead form or posts a trigger uses | The address a **Webhook** step calls, plus its headers, body and response mapping | | The automation a **Start another flow** step starts, and the sequence a sequence step adds to | The custom functions on an A.I. step | | The product, catalog products or WhatsApp form a step sends | The spreadsheet in a Google Sheets step | | The service a booking link offers, the class a step adds people to, and the staff member it assigns | | | The service, product or plan a step sends, the product whose stock it checks, the plan a subscription starts on, and what an order is for | | | The WhatsApp template in **Send template**, checkout-link, order-status and review-request steps | The Mailchimp audience | | The Google Business profile, number and channel a review request uses | The number a **Send SMS** step texts | | The stage in **Update contact**, and a condition that checks a stage or segment | How many credits an **Issue credits** step gives | | The teammate an **Assign to agent** or **Hand to human** step picks | | 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). `“” 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](#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 “”` 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**: | Status | What customers see | | - | - | | **Draft (customers can't see it)** | Nothing. Every new pack starts here. | | **Published** | The pack, in every customer's gallery. | | **Archived (hidden, kept)** | Nothing. The pack and its automations are kept so you can publish it again. | 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 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](#show-customers-only-your-packs): | Switch | A customer with no pack of yours for their type gets | | - | - | | **Off** | DMLY's pack for their type, or DMLY's **Front Desk Essentials** | | **On** | Your **Something else** pack if you have one, otherwise no pack at all. A DMLY pack is never handed out | 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](#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. If your agency is suspended, your customers see DMLY's packs in place of yours until it is active again, and new customers start with DMLY's pack for their business type. ## Who on your team can do this Three permissions under **Automation packs** when you build a role on **Team**: | Permission | Lets them | | - | - | | **View automation packs** (`packs.view`) | See the page and every pack on it. Ticked by default on a new role. | | **Create, edit and publish automation packs** (`packs.manage`) | Create, edit, publish, archive, delete and reorder packs, add, edit, move and remove automations, and change **Show customers only your packs**. | | **Copy automations from sub-accounts into packs** (`packs.import`) | Browse sub-accounts' published automations and copy them in, and give an API key the same ability when generating it. Copying also needs **Create, edit and publish automation packs**. | 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`](/api-reference/agency-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 The gallery, the preview, and switching a pack on. Open a sub-account to build and test a flow before you copy it. Build the automation you'll turn into a pack. Create and publish packs from your own systems. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.