Platform basics · Default tag library
Default tag library
New Navigator accounts start with a default library of tags — colour-coded categories that organise tasks and emails across every workflow in the platform. This article is the reference for what each default tag is for, who typically uses it, and how you should think about tags in your team's day-to-day.
What tags are for in Navigator
A tag is a short label attached to a task or email. Navigator uses tags for three things:
- Categorisation — so you can filter your queue to "just invoice tasks" or "just budget alerts" and work through one category at a time.
- Routing — account administrators can set up tag assignment rules that automatically assign tasks to specific team members based on their tag.
- Triggering workflows — some tags are system tags with specific behaviour attached. For example, the
supplier_bank_details_changedtag blocks all of that supplier's invoices until the associated task is complete. See System tags reference for those behaviours.
How to read this reference
The library groups tags into families using a [Family] prefix — [Accounts], [Claim], [Client], and so on. The prefix makes tags easy to scan in the task list: you can see at a glance whether you're looking at an accounts-side task or a claim-processing task.
Each tag in the tables below shows:
- Name — what appears in the Navigator UI
- Purpose — when to apply the tag
- Used by — the role(s) that typically act on tasks with this tag
The "Used by" column isn't a restriction — any team member can see and work any tag. It's a guide to who the tag is meant for, which helps with routing rules and picking work off the queue.
The default tag library
Accounts family
Orange tags (). Used by the Accounts / Payments / Finance team for financial adjustments, refunds, and NDIS upload errors.
| Tag | Purpose | Used by |
|---|---|---|
| [Accounts] General | General accounts info — for example, a credit note from a supplier. | Payments / Finance |
| [Accounts] Credit Note | A supplier has issued a credit note that needs to be applied. | Payments / Finance |
| [Accounts] Upload Error | An error occurred during PRODA upload or the NDIS rejected a claim at submission time. Code upload_error. | Payments / Finance |
| [Accounts] Refund Requested | A refund is being requested from a provider. | Payments / Finance |
| [Accounts] Refund Finalised | The refund has been received and the PRN has been cancelled. | Payments / Finance |
Bank Details family
Orange tags (). Used when a supplier's bank details need verification. See System tags reference — Supplier bank details changed for the full workflow.
| Tag | Purpose | Used by |
|---|---|---|
| [Bank Details] Change - Notice | Bank details have been updated in Navigator — the finance team needs to verify before invoices can be released. Code supplier_bank_details_changed. | Invoicing / Claims |
| [Bank Details] Change - Ph Req | Verification couldn't be completed via email — phone confirmation with the supplier is required before proceeding. | Invoicing / Claims |
Claim family
Cyan tags (). Used by the Invoicing / Claims team for every kind of claim document that arrives from a supplier.
| Tag | Purpose | Used by |
|---|---|---|
| [Claim] Invoice | The attached document is an invoice. Code invoice. Most common claim tag — applied automatically by AI classification. | Invoicing / Claims |
| [Claim] Quote | The document is a quote for future services. Code quote. | Invoicing / Claims |
| [Claim] Reimbursement | The claim is a reimbursement — the participant or contact has already paid and is claiming back. Code receipt. | Invoicing / Claims |
| [Claim] Receipt/Statement | The document is a receipt or account statement rather than a formal invoice. | Invoicing / Claims |
| [Claim] Duplicate | Confirmed duplicate — this claim has already been paid. | Invoicing / Claims |
| [Claim] Potential Duplicate/Paid | Looks like a duplicate but needs human review before confirming. Code duplicate. | Invoicing / Claims |
| [Claim] Future Service Date | The date of service on the invoice is in the future — can't claim yet. | Invoicing / Claims |
| [Claim] Reminder/Overdue | Supplier has sent a reminder or overdue notice for a previously-submitted invoice. | Invoicing / Claims |
| [Claim] Returned to Provider | Claim couldn't be processed and has been returned to the provider. Code returned. | Invoicing / Claims |
| [Claim] STR | Short Term Respite — a specialist claim category that needs additional review and experience. Route to senior claims staff rather than processing as a standard claim. | Invoicing / Claims (senior / specialist) |
Client family
Yellow-green tags (). Used by Intake / Onboarding team for the customer lifecycle.
| Tag | Purpose | Used by |
|---|---|---|
| [Client] New Pending Client | A referral has been received or the customer is pending onboarding. | Intake |
| [Client] Onboarding F/Up | The customer is mid-onboarding — follow-up is in progress. | Intake |
| [Client] Ceased Services | The customer has ceased (or is ceasing) services with your organisation. | Intake |
| [Client] Unknown Client | A communication arrived that we can't link to a known customer — needs investigation. | Intake |
Communications family
Yellow tags (). Some are applied automatically by Navigator (system-managed), others are applied by customer-facing staff to categorise incoming queries.
| Tag | Purpose | Used by |
|---|---|---|
| [Comms] Phone Call | The communication came from a phone call. Code call. Applied automatically when a call is logged. | System managed |
| [Comms] SMS | The communication came from an SMS. Code sms. Applied automatically when a message arrives. | System managed |
| [Comms] Live Chat | The communication came from a live chat session. Code live_chat. Applied automatically. | System managed |
| [Comms] Reply | A reply to an email previously sent from Navigator. Code reply. Applied automatically. | System managed |
| [Comms] File Note | Important correspondence that should be kept on file. | Customer-facing |
| [Comms] Details to Update | The customer, contact, or supplier has sent updated details that need to be applied. | Customer-facing |
| [Comms] Query - Client/SC | A query from a customer, contact, or support coordinator. Code comms_query_customer_contact. | Customer-facing |
| [Comms] Query - Supplier | A query from a supplier. Code comms_query_supplier. | Customer-facing |
| [Comms] SC Consent Form | A support coordinator consent form has been received or is in progress. | Customer-facing |
| [Comms] NDIS Exp Support | A query that needs NDIS expert support — the issue is more complex than usual and should be escalated to a team member with deeper NDIS knowledge. | Customer-facing, escalated to expert |
Evidence family
Teal tags (). Used for evidence supporting claim approvals — typical for assistive technology, capital items, and other claims that need supporting documentation.
| Tag | Purpose | Used by |
|---|---|---|
| [Evidence] Awaiting Evidence | A claim is on hold until supporting evidence is received. | Invoicing / Claims |
| [Evidence] Supporting Evidence | Supporting evidence for a claim has been received. | Customer-facing |
| [Evidence] AT - Check Docs | An assistive technology claim — documentation needs to be checked against the plan. | Customer-facing |
| [Evidence] NDIA Approval | Approval evidence received directly from the NDIA. | Customer-facing |
NDIS compliance family
Purple tags (). Used by Management and Accounts for NDIS-side compliance matters.
| Tag | Purpose | Used by |
|---|---|---|
| [NDIS] Fraud | Suspected or submitted fraud case. | Management |
| [NDIS] Payment Integrity | An NDIS payment integrity claim — the NDIS is auditing a payment. | Management |
| [NDIS] Provider Payment Enquiry | An NDIS Provider Payment Enquiry (PPE) that needs response. | Accounts, Management |
| [NDIS] PPE Submitted | A PPE response has been submitted. | Accounts, Management |
NDIS API family
Light orange tags (). System-managed tags applied when something arrives from the NDIS API. See API & integrations for detail.
| Tag | Purpose | Used by |
|---|---|---|
| [NDIS API] Error | The NDIS API returned an error that needs investigation (e.g. malformed response, unexpected rejection). Code ndis_api_error. | System managed · Invoicing / Claims |
| [NDIS API] Notification | The NDIS API sent Navigator an event (plan change, relationship change, budget update) that needs review. Code ndis_api_notification. See New & ended relationships. | System managed · Intake or Customer-facing |
Plan family
Light green tags (). Used by customer-facing staff and plan managers for plan-level issues — budgets, PACE endorsements, service agreements.
| Tag | Purpose | Used by |
|---|---|---|
| [Plan] Budget Alert | A budget threshold has been hit. Code budget_alert. Applied automatically by Navigator's alert system — see Budget alerts. | System managed |
| [Plan] PACE | A PACE notification arrived — plan change or related event. Code ndis_pace. | Intake |
| [Plan] PACE X | PACE endorsement error — the plan manager endorsement is broken or has ended. | Intake |
| [Plan] Ext SA | External service agreement / statement of service received. Code service_agreement. | Customer-facing, Plan managers |
| [Plan] Move $ in Core | Core funds need to be redistributed between support items. | Customer-facing, Plan managers |
| [Plan] Nil $/Expended Budget | Funds in a category are fully expended. | Customer-facing, Plan managers |
| [Plan] NDIS Plan/Breakdown | Participant's NDIS plan or RFS (request for service) inclusions need review. | Customer-facing, Plan managers |
Supports family
Lavender tags (). Track support item approval state for specific claims — typically seen on assistive technology or capital supports.
| Tag | Purpose | Used by |
|---|---|---|
| [Supports] Approved Support | A specific support item has been approved. | Customer-facing |
| [Supports] Declined Support | A specific support item has been declined. | Customer-facing |
| [Supports] Replacement Support | The support is a replacement for a previously-approved item (e.g. equipment replacement). | Customer-facing |
Standalone tags
Tags without a family prefix — usually system-managed flags or cross-cutting priority labels.
| Tag | Purpose | Used by |
|---|---|---|
| Onboarding | Applied automatically to tasks created as part of the customer onboarding workflow. Code onboarding. | System managed |
| Support Plan | A support plan record is involved. Code support_plan. System-managed. | System managed |
| Approval Follow-up | Applied automatically when an invoice approval request hasn't had a response and needs chasing. Code invoice_approval_followup. | System managed · Customer-facing |
| Retention | Customer retention work — typically follow-up after a churn-risk signal. Code retention. | Customer-facing, Management |
| Unclassified | Navigator couldn't confidently categorise the task or email. Code unclassified. A prompt to apply a more specific tag. | System managed · any team |
| ‼️ Urgent | Cross-cutting priority flag — pushes a task to the top of your queue regardless of tag family. | Any team |
| 🚫 Blocked Email | Navigator tried to send an email to a blocked address. See Blocked email address. | System managed · Customer-facing |
| Spam | The communication is junk and should be archived. Applied manually or via automation rules. | Any team |
Which roles use which tags
If you're orienting to Navigator by role rather than tag, here's the reverse view. Each role's role landing page pulls related articles together for that team — but this is the quick tag-level summary.
| Role | Primary tag families |
|---|---|
| Intake / onboarding | [Client] (all), [Plan] PACE + PACE X, Onboarding |
| Customer-facing / engagement | [Comms] (most), [Evidence] (most), [Plan] Move $ in Core, [Plan] Nil $, [Plan] NDIS Plan/Breakdown, [Plan] Ext SA, [Supports] (all), Retention, Approval Follow-up |
| Invoicing / claims | [Claim] (all), [Bank Details] (both), [Evidence] Awaiting Evidence, [NDIS API] Error |
| Accounts / payments / finance | [Accounts] (all), [NDIS] Provider Payment Enquiry, [NDIS] PPE Submitted |
| Senior / specialist staff | [Comms] NDIS Exp Support (complex queries escalated from customer-facing team) · [Claim] STR (Short Term Respite — specialist claim rules) |
| Management | [NDIS] Fraud, [NDIS] Payment Integrity, Escalations generally |
| System-managed (applied automatically) | [Comms] Phone Call, SMS, Live Chat, Reply · [Plan] Budget Alert · [NDIS API] Error, Notification · Onboarding · Support Plan · Approval Follow-up · Unclassified · Blocked Email |
How tags drive work
Understanding what a tag means is only half the picture. The reason tags are powerful in Navigator is that they flow through to three operational surfaces:
Filtering your queue
Filter the task queue by a tag to work a batch of similar tasks back-to-back. Good examples:
- Filter to [Client] Onboarding F/Up at the start of the day to chase all in-progress onboardings in one sitting.
- Filter to [Claim] Duplicate and [Claim] Potential Duplicate/Paid to clear duplicate investigations in a batch.
- Filter to [NDIS API] Notification to clear the PACE events your team needs to review.
See Tasks by tag for the filtering UI.
Automatic task routing
Your administrator can create tag assignment rules so that new tasks with a specific tag are auto-assigned to the right team member. For example:
- New tasks tagged [Accounts] Refund Requested → assigned to the accounts team automatically.
- New tasks tagged [Client] New Pending Client → assigned to the intake coordinator.
- New tasks tagged [Claim] Invoice with low complexity → available for junior claims staff.
- Tasks tagged [Comms] NDIS Exp Support → routed to senior staff with deeper NDIS knowledge for complex query escalation.
- Tasks tagged [Claim] STR (Short Term Respite) → routed to senior claims staff — STR has specialist rules that need experience.
Rules combine tag + complexity. See Tag assignment rules for setup.
Automatic tag application
Three things cause a tag to be applied automatically:
- AI classification. When an email arrives, Navigator's AI reads it and applies tags like [Claim] Invoice, [Claim] Quote, [Comms] Query - Client/SC. See AI email categorisation.
- Keyword matching. Tags can have keywords defined on them (e.g. the
[Accounts] Upload Errortag has keywordsaccounts, upload, error). When a keyword appears in an email, the tag is applied. Configured per tag in Settings → Tags. - Automation rules. Your administrator can set up rules that apply tags based on sender, subject, or body content. See Email automations.
Behaviour tags
A small set of tags have specific effects beyond categorisation — for example, supplier_bank_details_changed blocks all of that supplier's invoices until the related task completes. These are documented separately in System tags reference.
Customising for your account
The default library is a starting point — adjust it as your workflow matures.
How to customise
Go to Settings → Tags. From there you can:
- Add new tags — give them a name, colour, and optional keywords for auto-tagging
- Rename tags — the display name can change; tasks already tagged keep the tag
- Change colours — to make your most-used tags visually distinct
- Remove unused tags — tags your team never uses clutter the picker
- Set priority — tags with higher priority appear earlier in the tag selector
You need the tag.create, tag.update, or tag.delete permission depending on what you're doing. See Roles & permissions.
code attached (e.g. invoice, onboarding, supplier_bank_details_changed, ndis_api_notification) — the code is what Navigator uses internally to trigger workflows. You can rename the display name freely, but the code is what matters. If you're unsure which tags have codes, check with your Kismet contact before making changes.
Tips for tag hygiene
- Prefix new tags with a family label in square brackets. Matches the default convention and keeps tasks scannable in the queue.
- Colour-code by family, not by individual tag. All Claim tags cyan, all Accounts tags orange — this makes tasks visually grouped in the queue.
- Use the priority field on high-use tags. Higher priority = appears earlier in the selector.
- Don't create overlapping tags. If "Refund Requested" and "Refund Pending" both exist and mean the same thing, pick one and delete the other.
- Regularly filter for Untagged tasks and apply the right tag. Tasks that slip through with no category are hard to route and hard to prioritise.