Who Can See a Digital Shift Note? Questions to Test Before You Choose an App

A practical checklist for testing exactly who can see a digital shift note, with a fictional example comparing a shared team record to a solo client file.

Published 25 October 2026. Published by Sparks Support Pty Ltd, the makers of Sparks Provider.

The short answer

A shift note should only be visible to people currently rostered to that client, not everyone who has ever worked with them. Before choosing an app, create fictional test shifts and check exactly who can open each note, incident report and attached file.

Who can actually open a shift note once it has been submitted? That single question decides whether a digital note-taking tool is safe to roll out across a team, or only ever meant for one person managing their own small caseload. Do not take a sales page's word for it. Test it with invented, anonymous shifts before you move real work across.

The answer also depends on what kind of record you are building. A sole support worker managing their own clients needs a personal file that travels with them. A small provider team needs a shared record that hands information from one rostered worker to the next, while keeping some things, like incident reports, tighter than the general note. Confusing the two is where privacy problems start.

• Create two or three fictional, anonymous test shifts across different workers and clients
• Log in as a test worker account and note exactly what they can and cannot open
• Add a note, a photo and an incident to one shift, then check who sees each one separately

Does a worker see notes for a client they have never supported?

This is the first and most important test. Imagine a fictional, anonymous example: Worker A is rostered to Client One on Tuesdays, and Worker B is rostered to Client Two on Fridays, with no overlap. Open Worker B's account and search for Client One. If anything at all appears, that is a real gap. A sound system only shows a client's history to people who have actually been rostered to support them.

Does removing a future shift erase what someone already saw?

Take your fictional Worker A off Client One's roster going forward and check two things: can they still see shifts they are no longer booked for, and does the system pretend they never saw the earlier notes at all? Removing a future booking should stop new access. It is reasonable for it not to retroactively hide what was legitimately read at the time, but you want to know which behaviour you are getting.

Are incident reports kept separate from ordinary shift notes?

Write a fictional incident report against a test shift, then check who can open it. An incident is different from a routine handover note and often needs a tighter circle, typically the person who wrote it and the business's owners or admins, rather than every worker rostered to that client. If an incident shows up in the same general feed everyone else reads, that is worth noticing before you rely on it.

Who can open the photos and files attached to a note?

Add a fictional photo to a test note and check two things: does everyone with access to the note also see the photo, and is there a record of who added or removed it? A photo taken without consent, for example, needs to be removable, and that removal should leave a trace rather than silently disappearing.

Can a submitted note be edited, or only added to?

Try to change a fictional note after submitting it. A record you can quietly rewrite later is a weaker record. Look for a system where a submitted note stays as it was written, with corrections added as a new, timestamped entry that references the original, rather than the original text changing underneath you.

Is there one record per client, and who can pull it together?

Check whether all of a fictional client's notes sit in one place, viewable across a date range, and whether that view can be turned into something you can hand to a family member or a coordinator on request. Also check who has permission to do that. This kind of export is usually something you want restricted to owners and admins, not every rostered worker.

Is this your personal client file, or a shared team record?

This is the distinction to settle before anything else. A personal file belongs to one independent worker and their own clients. A shared record belongs to a provider team, where the Thursday worker needs to see what happened on Tuesday, and a worker who has never supported that person sees nothing. These are genuinely different jobs, and an app built for one does not automatically suit the other.

This site is run by the team behind Sparks Provider, so it is worth naming that upfront. Sparks Provider is built for running a provider team, where notes follow current rostered access and incident reports stay with the author and admins. The same team also makes Sparks Scribe, a separate tool for an independent support worker managing their own client work with shift notes and invoicing. They are not the same product and do not automatically share records, so if your situation is a sole trader rather than a team, that distinction matters more than any feature list.

Whatever you choose, do not take visibility claims on faith. Build a few fictional test shifts, invite a test account, and watch what actually happens before a single real client note goes into the system.

This article is general information about provider operations and Sparks Provider. It is not legal, financial, employment, NDIS or compliance advice. Check current requirements with the relevant authority or an adviser for your business.

Need a simpler way to run your provider business? Explore Sparks Provider. $499 a year including GST, with unlimited staff and clients.

Questions or corrections? Contact the publisher. Please do not send client or health information.