Why these workflows are documented: SupportFlow is designed to reduce repetitive administration while preserving deliberate checks around billing, records, privacy and backups. Some additional steps, warnings and record locks are intentional safeguards rather than unnecessary friction. Testers should assess both whether a workflow is easy to use and whether these safeguards operate at the correct point without preventing legitimate corrections.
Testing convention: report where the observed path, labels, validation, calculations, locking or completion state differs from the flow shown here. Privacy, NDIS record-keeping and tax/legal statements should be tested as guidance, not as guarantees.
1
First-time onboarding
Expected path from first launch to a usable SupportFlow workspace.
Open SupportFlow
→
Optional app lock / PIN
→
Create required backup password
→
Connect Google Drive
→
Press Continue
→
First encrypted backup starts
→
Backup succeeds?
→
Step 1: Your details
→
Step 2: Plan managers
→
Step 3: Participants
| Backup fails | Stay on backup screen. Show clear error / Try again. Do not advance onboarding. |
|---|---|
| Backup succeeds | Continue into setup. In production onboarding, Google Drive connection and the first successful encrypted backup are required before Continue can advance. Drive cannot be skipped at onboarding. It can be disconnected later from Settings because the user retains control of their backup account; disconnecting stops future automatic Drive backups on that device. |
| Plan managers | Add company/contact/accounts email/payment terms, or choose that none are used. |
| Participants | Add NDIS participant or private non-NDIS client, plan management, usual item/rate, area and agreement status. |
Why: Working records are local-first. Requiring an initial encrypted Drive backup reduces loss risk if a device is lost, replaced, damaged or local app/browser data is cleared. Later disconnect exists because the Google account remains under the user's control.
2
Participant setup
Expected setup for NDIS and private non-NDIS clients.
People > Participants
→
Add participant
→
NDIS or private client?
→
Enter identity & billing details
→
Save participant
| NDIS participant | Record name + NDIS number. Select plan managed, self managed or NDIA managed. |
|---|---|
| Plan managed | Link an existing plan manager so invoices are addressed to that organisation. |
| Private client | Tick 'Not an NDIS participant, private client'; use free-text service description and own rate. |
| Usual support item | Sets the participant's normal item. Actual invoice lines use the delivered shift/date/time classification. |
| Travel area | Sets travel-time cap according to the participant's configured area. |
| Agreement | Signed status can be recorded now or managed later under People > Agreements. |
Why: The usual support item reduces repetitive setup, while actual shift timing remains authoritative for billing classification. A saved default should not override the support actually delivered.
3
Create and manage a shift
Expected shift lifecycle and status handling.
Work > Shifts
→
Add a shift
→
Participant + date + start/finish
→
SupportFlow classifies applicable item
→
Save
| Future date | Status is Scheduled. It appears on the calendar but is not offered for invoicing. |
|---|---|
| Today / past | Status is Completed and becomes available to invoice. |
| Past still scheduled | App shows 'did this go ahead?' with a Yes action. Choosing Yes changes the shift to Completed and makes it available to invoice. There is no inline No action in this prompt; if the shift did not occur, open the shift and record it as Cancelled using the normal shift controls. |
| Cancelled | Keep as a record; capture cancellation timing. Claimability depends on applicable conditions and agreement. |
| Edit / delete before lock | Before a shift is attached to an invoice, the worker can correct or delete it through the normal shift controls. Once attached to an invoice, billing locks apply so the work record and invoice cannot silently diverge. |
| Invoice safety | A scheduled future shift must not be offered for billing. |
Why: Records remain correctable while they are ordinary working records. Billing locks begin when work becomes part of an invoice, protecting invoice/work-record consistency without blocking legitimate corrections beforehand.
4
Complete a shift
Expected hand-off from work record to the related admin tasks.
Open shift
→
Confirm work occurred
→
Status = Completed
→
Add progress note if needed
→
Record travel if applicable
→
Completed work
→
Ready to bill
→
Select on Money > Invoices
→
Raise invoice
| Validation focus | Completing a shift should preserve the participant/date/time context. Related travel and invoicing must remain associated with the correct participant and date, and work should not disappear from billing eligibility. |
|---|
Why: Completion is the hand-off between recording work and billing it. Participant, date and time context must carry through so notes, travel and invoicing remain tied to the correct delivered support.
5
Progress / shift notes
Expected rough-note to structured-note workflow, including sharing.
People > Notes
→
Select participant/date
→
Write or paste rough factual notes
→
Tidy this up
→
Review structured note
| AI assist | Sort only what was supplied into: Support provided; Participant involvement; Progress toward goals; Observations; Follow-up. |
|---|---|
| Missing section | Leave it marked missing. Do not invent information. User may add a factual line or leave it blank. |
| No AI assist | User can save the original plain-text note exactly as written. |
| Private | Saved for the worker's own records; nothing is sent automatically. |
| Shareable | User reviews, then may use Send this note. Sharing is a separate deliberate action. |
| Identity option | User chooses whether full name + NDIS number are included when sending. |
| Send record | Where SupportFlow knows the destination, such as a direct participant or plan-manager email, record when and to whom it was sent. When the device share sheet is used, SupportFlow must not guess which app or person was selected; record it as shared from this device with the recipient not recorded. |
Why: The note assistant structures only facts supplied by the worker. Review remains deliberate because SupportFlow should organise documentation, not invent participant information or automatically disclose a note.
6
Travel & kilometres
Expected travel recording and dual-use behaviour.
Work > Travel
→
Date + participant
→
Enter km or odometer readings
→
Billable?
→
Save trip
| Billable kilometres | Trip can be selected for an invoice and carries the configured travel charge. |
|---|---|
| Travel time | Optional minutes appear when billable; treated separately from kilometres and follows configured cap/rules. |
| Vehicle record | Recorded kilometres also feed the vehicle/tax deduction records - entered once. |
| Not billable | Keep the travel record without adding it to an invoice. |
7
Create, send and track an invoice
Expected invoice construction from completed work.
Money > Invoices
→
Ready to bill
→
Tick completed work for one participant
→
Raise invoice
→
Review invoice
→
Preview PDF
→
Share invoice
→
Status = Sent
→
Payment received
→
Mark Paid
| Line construction | Each selected shift remains its own invoice line with date, start/finish and applicable support item. |
|---|---|
| No double billing | Once attached to an invoice, the underlying shift/trip is treated as billed and is excluded from other invoice selections. Invoice lines are read-only: rate, quantity and delivered-work details are not edited directly on the invoice. If the underlying work is wrong, correct the source shift/trip rather than allowing the invoice to drift from the work record. Deleting an invoice releases its underlying work so eligible items can return to Ready to bill. Sent or paid invoices should be handled deliberately because deleting them removes invoice history. |
| Nothing forgotten | The warning appears in the invoice editor whenever other eligible shifts or billable trips for that participant are still unbilled. It is a nudge only: it does not silently add them to the current invoice. The user returns to the Ready to bill selection to tick work that belongs on an invoice; otherwise those items remain waiting for a later invoice. |
| Overdue | Sent + past due + unpaid displays Overdue. The due date comes from the applicable payer/payment terms. Plan-managed work uses the linked plan manager's terms; private/self-managed billing uses the payment terms configured for that payer/client. |
| Tax link | Only invoices marked Paid count as income for the running tax estimate. |
Why: Invoice locks and the 'nothing forgotten' check reduce duplicate billing, omitted work and later inconsistencies while still allowing draft corrections before an invoice is sent.
8
Service agreements
Expected agreement generation and status tracking.
People > Agreements
→
Select participant
→
Generate one OR mark as signed
→
Set dates/details
→
Track review status
| Generate one | Build PDF from existing participant/business/service/rate/travel/payment information with signature blocks. |
|---|---|
| Mark as signed | Record signed state; today's date can be filled if not already set. |
| Dates and details | Maintain date signed, review date and where the signed copy is kept. |
| Review warning | Agreement approaching review date is surfaced so the worker can follow it up. |
| Legal status | Generated agreement is a starting point, not legal advice. |
Why: Existing participant and business information is reused to reduce repetitive administration, while signed/review status stays explicit because the worker remains responsible for the agreement and its currency.
9
Expenses, Money and tax estimate
Expected financial record flow.
Record paid invoices
→
Record expenses
→
Record vehicle kilometres
→
Money totals update
→
Running tax estimate updates
| Income | Driven by invoices marked Paid, not merely created/sent invoices. |
|---|---|
| Expenses | Business expense records feed the financial summary and relevant estimate calculations. |
| Vehicle | Recorded kilometres support the vehicle deduction comparison/records available in the app. |
| Tax estimate | An estimate based on app records; it is not tax advice or a lodged tax return. |
| GST | GST status is configured under Settings > Business & invoice. That business-level setting changes invoice presentation/calculation where applicable, so GST treatment is not repeatedly chosen on each invoice. |
Why: Paid income, recorded expenses, kilometres and business-level GST settings feed the financial view consistently. The tax figure remains an estimate, not a tax return or personal tax advice.
10
Google Drive backup & restore
Expected local-first encrypted backup workflow.
Meaningful local change
→
Wait ~5 minutes after the latest meaningful change
→
Encrypt backup on device
→
Upload encrypted file to connected Drive
→
Record last successful backup
| Automatic timing | The five-minute automatic-backup timer is debounced: each new meaningful change resets the timer. The backup runs about five minutes after the latest change, not five minutes after the first change in a burst of edits. |
|---|---|
| Back up now | Starts one immediate backup. While running, button shows Backing up... and duplicate attempts are blocked. |
| Offline / failure | Do not report success. Keep pending/retry state and show failure clearly where appropriate. |
| Restore | Connect the appropriate Drive account, select an encrypted backup, enter the password that created it, then decrypt locally. If the password is wrong, the file is corrupt/incompatible, download fails or decryption fails, stop the restore, show a clear error and leave existing local records unchanged. The user can retry or select another backup. |
| Change account | Reconnect to a different Google account; create a fresh backup there. |
| Disconnect | Stops automatic Drive backup on that device; existing Drive backup files are not automatically deleted. |
| Storage model | Working records remain local; Google Drive stores encrypted backup copies. |
11
Help & SupportFlow Assistant
Expected route when a user needs guidance.
Tap ?
→
Choose help route
→
Ask SupportFlow
→
OR Manual & Help
→
Return to task
| Ask SupportFlow | Ask how to use the app. The assistant should answer from app/help context without needing participant records. |
|---|---|
| Manual & Help | Open the relevant main topic and follow step-by-step guidance. |
| Privacy | Do not enter participant personal, health or sensitive information into the Assistant. |
| Scope | Assistant guidance is for using SupportFlow; it does not replace professional NDIS, tax or legal advice. |
12
Settings, security & privacy
Expected settings and protection workflow.
Settings
→
Choose collapsed panel
→
Update required setting
→
Save / apply
| App lock | Optional PIN / supported biometric protection for access to the local app. |
|---|---|
| Business & invoice | Maintain name, ABN, GST/contact and bank details used on invoices. |
| Backup | View Drive connection, last successful backup, Back up now, restore, change account or disconnect. |
| Privacy & security | Explain local record storage, encrypted Drive backups, external-service sharing and legal-document links. |
| Legal documents | Public Privacy Policy and Terms of Use remain the formal legal documents. |
Flow convention: Decision points use one consistent rule: the decision appears in the workflow path and each possible outcome is explained directly below it. Testers should exercise each applicable branch, including success/failure, billable/not billable and locked/unlocked states.
Tester reporting format: Workflow number → step → expected result → observed result → severity → screenshot/video → device/browser.
Scope note: SupportFlow does not use a conventional cloud account/sign-in session for its working records. Records are local to the installed app/browser, with encrypted backup copies stored in the connected Google Drive. Multi-device live synchronisation and automatic conflict merging are not part of this workflow pack; a Drive backup is a backup/restore mechanism, not a shared live database.