The stack editor

The stack editor is where you shape a stack around how your team actually works. Open a stack and click the pencil (Edit stack) next to its name (you'll need to be the stack's Owner or a Manager, see Who can see a stack).

The seven steps

Each step does one job, and the stack's stages show up where they matter, so you always see what you're shaping. Move between steps with the step names across the top, Back and Next at the top right, or the same buttons at the bottom of each step (Continue to the next step) so you don't have to scroll back up.

1. Name. The stack's name, a short description and its ticket ID prefix (like FR, so tickets are FR-1, FR-2). The prefix locks once the first ticket exists, so ticket numbers never change under people. Here you also pick the stack's color and, if you like, an Icon for its colored square: click Choose an icon, search ("truck", "money") or browse the groups, then pick the Icon color (Automatic picks whichever reads best). Stacks made from a template start with an icon; Remove gives a plain square.
2. Fields. What you need to know about every request. Click one on the left to add it, then click it on the ticket to set it up. See Ticket fields.
3. Getting in. Every way work reaches the stack: in the app (always on), the web form or QR code, email, schedules and the API. On a brand-new stack, switch on the web form or email here and they go live when you click Save stack.
4. Stages. A canvas of the stages a ticket goes through, each with one or more steps, and who gets each step's tickets. Start from a common one (Simple, Approval, Orders or Repairs) or build your own; stages can branch, and a step can be an approval. See Statuses and steps.
5. Rules. The same canvas: click a step to say what has to be filled in before a ticket moves on. See Step rules.
6. Automations. The same canvas again, optional: click a step to send a heads-up, nudge tickets that sit too long, fill in a field or tell another app. Due-date reminders are in Stack settings. Skip for now if you'd rather come back later. See Automatic actions.
7. Sharing. Who can see the stack and what everyone can do, plus anyone who gets more or less. See Who can see a stack.

Drafts and publishing

The first time, you click Save stack and it's live. After that, your edits autosave as a draft while you work, and your team keeps using the version they know. When you're happy, click Publish changes (it's at the top on every step once there's something to publish) and everyone gets the new version at once. Under the stack's name you'll see "Changes not live yet" until you do. Discard changes puts everything back the way it's published, and Undo takes back your last change. If you close the editor with changes that aren't live, it asks whether to publish them, keep them as a draft (Keep as a draft) or discard them.

Why work this way? You can rebuild a whole process on a Tuesday afternoon without anyone seeing a half-finished form or a ticket landing in a step that doesn't exist yet.

Existing tickets come along when you publish: they can move into new statuses and steps, and they show new fields right away. If you removed a step, tickets still sitting in it keep the old design until you move them, so nothing gets lost.

Tips

• Every field, status and step keeps a permanent identity, so renaming is always safe: old tickets, reports and saved views follow the new name.
• Start small. You can add a rule or a reminder next week once you see where tickets get stuck.