Most of building a workflow happens on the Build tab — steps and items. But a workflow also has a handful of workflow-level controls that decide how deals are created, how the workflow is versioned, and when it goes live. This guide covers the Settings and History tabs, self-registration, and the publish step. (The Preview tab has its own guide — Preview: Control the Look & Feel.)
Everything here is in the workflow builder at https://input.ziplineos.com.au. For the workflow vocabulary, see Order Workflows.
Settings
The Settings tab holds the deal-level context for the workflow:
- Name and Description — how the workflow is identified.
- Theme Color — the workflow's accent on the board.
- Deal Value Field Key — which form field supplies a deal's headline value (used in reporting and the board).
- Default entry step per creation source — where a new deal lands depending on how it was started: Web (anonymous self-reg), Manual, or API.
- Manual creation form — the questions asked when a staff member creates a deal by hand.
Self-Registration
Turn on Allow Self-Registration and the workflow exposes a public URL: "When enabled, anonymous customers can start a new application via a public URL." Every visit to that link starts a new deal, so you can put it on your website or share it on social media and let customers begin applications themselves.
When the toggle is on, set a Registration Path — the slug at the end of the link (lowercase letters, numbers, and hyphens, at least 4 characters; e.g. apply). The builder then shows the full public URL:
https://{your-subdomain}.collect.ziplineos.com.au/{registration-path}
The {your-subdomain} part is your organisation's Collect subdomain — set once for the whole org (next section).
Self-registration deals arrive anonymous and unqualified. Pair it with a Lead stage type on your entry step so these deals stay hidden from the team until someone qualifies them — see Order Workflows.
Setting your Collect subdomain
The subdomain (and your portal branding) is configured in the Identity portal, not the workflow builder — and you need to be an admin or owner of the account.
- In the Identity portal, open your organisation in the hierarchy.
- Go to the Client Portal tab.
- Under Client Portal Subdomain, set the Subdomain field — e.g.
acmegivesacme.collect.ziplineos.com.au. Letters, numbers, and hyphens only (3–63 characters). - Under Portal Branding, set the Primary Brand Color and a Logo URL to brand the client-facing portal.
- Save.
Set the subdomain and branding once, before you share any self-registration links. Every workflow's public URL is built from this one subdomain, so getting it right up front means none of your links change later.
History — versions and publishing
The History tab is a read-only audit of every published version, showing what changed between them — which entity, which property, and the old and new values. From here you also Publish: "Click Publish to snapshot the current workflow as a new version."
Publishing takes an immutable snapshot of the entire template. Deals lock to the version that was live when they were created, so editing a published workflow never disturbs deals already in flight — your changes only affect new deals. (If your account has the Drafts & Versions feature, you publish from there instead, and the History tab points you to it.)
You must publish before a workflow can take deals
A brand-new workflow is in Draft. While it's a draft it has no board, no Kanban, and can't create real deals — and it doesn't appear in the Input Hub navigation at all. Only published workflows are listed there.
This trips people up: "How do I test it while I'm still building it?" The answer is to publish it once. After the first publish, the workflow appears in the left navigation; open it to get its Kanban board, create and test deals, and switch between views. You can keep editing afterwards and re-publish — existing deals keep their version, new deals pick up the latest.
See the FAQ Why doesn't my new workflow show a board or let me create deals? for the short version.
Things to keep in mind
- Publish is the go-live switch. Nothing about a workflow is usable for real deals until its first publish.
- One subdomain, many links. Every self-registration URL hangs off the org's single Collect subdomain — set it before sharing links.
- Editing a live workflow is safe. In-flight deals keep their snapshot; re-publish to roll changes out to new deals.