A workflow has two kinds of roles, and they answer two different questions. Applicant roles describe the external people on a deal — the applicants filling it in. Team roles describe your internal people — the staff who do work inside the deal. Once both are defined, you can assign any item to a specific role so the right person, and only the right person, gets that piece of work.
Roles are configured in the workflow builder at https://input.ziplineos.com.au. This is an advanced setup — simple workflows can leave every item open to anyone. For the workflow vocabulary (template, step, item, deal) start with Order Workflows.
Applicant roles
Applicant roles are the participant types a deal expects — for a lending deal, that might be Primary Applicant, Co-Borrower, and Guarantor. You define them per workflow: each role has a name, an optional description, and how many of that role a deal needs (its minimum and maximum count). The counts drive how many copies of a person's forms appear; see Scope, Cardinality & Repeatable Items for the detail.
Applicant roles let a form ask the right person the right thing — the guarantor's declaration goes to the guarantor, not to every applicant.
Team roles (Internal Roles)
Team roles are your own staff roles — Broker, Administrator, Support, and so on. They come from the member types defined in the Registry, so they're consistent across every workflow. On a workflow's Team Roles tab you switch on the ones this workflow uses:
| Column | Meaning |
|---|---|
| Enabled | Whether this role is in play for the workflow. |
| Role | The member-type name (e.g. Broker). |
| Code | The member type's short code. |
| Required | Whether the deal expects someone in this role. |
Team roles are sourced from the Registry. If the Team Roles tab is empty, no member types exist yet — create them in the Registry first, then return to enable them here.
Assigning an item to a role
Open any item (most commonly a Form) in the builder. Its Role picker — "who completes this" — offers:
| Choice | Who can complete the item |
|---|---|
| Any | Anyone on the deal. The default. |
| An Applicant Role | Only that applicant (e.g. only the Guarantor). |
| An Internal Role | Only staff in that team role (e.g. only an Administrator). |
The picker groups choices under Applicant Roles and Internal Roles subheaders, so it's clear whether you're handing work to a customer or to your team. Assigning an item to an internal role makes it part of that person's work on the deal — the next thing a Broker or Support agent has to clear before the deal moves on.
Worked example
Goal: the Primary Applicant fills the fact-find; an Administrator clears a final check.
- In the workflow, define applicant roles Primary Applicant and Co-Borrower.
- On the Team Roles tab, enable Administrator.
- On the "Fact Find" form item, set Role = Primary Applicant.
- On the "Final Review" validation item, set Role = Administrator (an Internal Role).
The fact-find now appears only for the primary applicant, and the final review sits with your admin team rather than the customer.
Things to keep in mind
- Keep applicant roles to what the process needs. Each role you add can multiply the forms a deal generates. Add Guarantor only when a deal can actually have one.
- An item left on "Any" is open to everyone. Restrict only where it matters — over-restricting can leave work with no one able to do it.
- Team roles depend on the Registry. Renaming or removing a member type in the Registry flows through to every workflow that uses it.