What we store, and who can see it
There is nowhere in this product to type anything about the people your agency supports. Everything below follows from that.
We hold nothing about the people in your care.
No residents. No patients. No diagnoses, support plans, care plans, service notes, behavior data, medication records, incident reports or ISPs. There is no field for it, no import that accepts it, and no setting that turns it on.
This is the single most useful thing we can tell you about the risk of using it. The moment a scheduling tool stores information about the people you support, it becomes a healthcare records system, with every obligation that carries — and the breach that matters stops being "someone learned who works Tuesdays" and becomes something you have to notify people about.
Keeping it to workforce data makes it simple to approve and simple to audit. A stolen copy of this database would tell someone who works where. It would not tell them anything about the people you support, because none of that is in it — that is a fact about what the product holds rather than a claim about how well anything is defended, and it is the comparison worth making about any vendor.
Certification tracking is on to begin with and can be switched off. You can record a certification name and an expiry date against a person; publishing a week names anyone whose certificate has lapsed before a shift in it, for a scheduler to confirm. It never refuses a shift. We do not verify a certificate, store a copy or scan of one, or claim to know what your state requires — the record is the name and date you entered.
Position marks work the same way and always have: you mark someone as a med aide, a CNA or an LPN, and the product warns a scheduler who assigns them outside the positions they hold, and stops a staff member claiming an open shift they are not marked for.
Everything that is in the database.
That is everything. If it is not on this list, we do not store it.
| What | Why it is there |
|---|---|
| Staff | Name, work contact details, the positions they hold, the locations they work, the hours they prefer and the days they are available. If you fill it in, their id in your own payroll system, which we never use for anything except putting it in the hours file you export. This is what makes a schedule possible at all. Also, where you fill them in: a hire date, and any private note you write on their record, which no staff member can see. |
| Locations and positions | Your homes, day programs and offices, and the roles you staff them with. Named by you, in your own words, with an address and a note on each if you add them. Staff see the name of a home they are working, never the list or the addresses. |
| Shifts and assignments | Who is scheduled where and when, including the recurring patterns those weeks are generated from, and whether a week is a draft or published. |
| Attendance | Call-offs, late arrivals and no-shows, each with the date it happened, who recorded it, and any note they wrote. |
| Time off | Dates someone is unavailable, so the product refuses to schedule over them. |
| Logins | Email address, the password in hashed form, the role you gave them, and their current sessions. Never the password itself. Also a count of consecutive failed sign-ins and, if a login is locked, when the lock lifts. For a scheduler you have narrowed, which sites each scheduler is allowed to change. |
| Invite links | When you invite somebody, a single-use link is stored until it is used or expires, then it is gone. It is the one thing here that is not kept: it is a key, not a record, and it is left out of our backups on purpose so that restoring a backup cannot bring an old invite back to life. |
| Assistant usage | If you type a request to the assistant, we store that somebody did — which login, and when. Not what you typed, and not what came back. It is a counter, and its only job is a daily limit so that a stuck browser tab cannot run up a model bill. Listed here because a complete list has to include the boring rows. |
| Billing state | Your billing email, your invoice history and a Stripe customer reference. Never a card number — those are entered on Stripe's own pages and never reach us. We also keep one headcount reading per month, which is what the bill is worked out from. |
| Messages | If you use the Messages add-on: what was sent to a staff member, what they replied, when each was sent and whether it has been read. Message text is stored as written, because a message someone was sent is a record of what they were told. One conversation per person — there is no group thread. |
| Notifications | For each device a staff member has turned notifications on for: the address their browser gave us to deliver to, the keys that encrypt the message to that device, and the browser it was registered from. Enough to send a notification and nothing else — not a phone number, and no location. |
| Shift requests | When a staff member asks for an open shift or offers one of theirs to a colleague: who asked, which shift, any note they typed, and what the scheduler decided. Kept after the decision, so a shift that changed hands can be explained later. |
| Reliability | If you switch scoring on: the score itself is worked out from the attendance above and never stored as a number. What is stored is the bonus rules you set, and any extra pay you attach to a specific shift to get it covered, with the note explaining it. |
| Certifications | If you switch certification tracking on: the name you gave a certificate, the expiry date you entered, and whether a lapse should stop the schedule or only warn. Never a scan, a copy or a licence number — we hold the date you typed and nothing that would prove it. We also keep a note of which expiry reminders we have already sent, so nobody is told the same thing twice. |
| Our own notes about your agency | A private note field we use for sales and support — what you asked for and what we agreed. |
| Schedule history | Who removed or changed a shift, which one, and when. Append-only — nothing edits or deletes it, which is what makes it worth anything if a licensing review asks about a particular date. It is also how the app knows a shift you removed on purpose should stay removed rather than being rebuilt from your master schedule. |
The authoritative version of this, with retention periods and every third party involved, is the privacy policy. This page is the plain-English one. How the parts of it work — password hashing, sessions, the staff boundary, our backups — is in Technical detail at the foot of the page.
Who can see what.
Four roles. Administrators see everything for your agency, schedulers build and change schedules, staff see their own shifts, and the platform owner — us — manages accounts, billing and sign-in problems without a route into your schedules.
If you run more than one site, a scheduler can be narrowed to the sites they run. A narrowed scheduler can change shifts only at their own sites, and sees on their roster only the people who work at one of them — plus anyone not yet assigned to a site, so a new hire is never invisible to the person who needs to schedule them.
They still see the whole agency's schedule, on purpose. Someone who works at two of your homes carries one set of hours, and the reason they cannot take Thursday is usually a shift at a house their scheduler does not run. Hiding it would turn a visible conflict into an unexplained refusal. Every scheduler starts agency-wide; narrowing is something an administrator does deliberately, on the Logins screen.
- An unpublished schedule. Drafts are a scheduler's working copy.
- Any colleague's name on a shift — they see a count of who is on with them
- Anyone else's hours, availability or time off
- Attendance records, other than the facts behind their own score
- A supervisor's written note about an incident, or who wrote it
- Any other agency's anything
A staff member's screens are built to return only their own information. They are not everyone's schedule with the rest hidden — the rest is never fetched, so there is no setting anybody could get wrong.
Agencies work the same way: every request is tied to one agency. Only we can cross that line, and only on the screens that show accounts and billing. So we can answer “I cannot sign in”, we can also look up a person by name or email to see their role and whether they are locked out.
None of it reaches a schedule, a shift, an assignment or an attendance record.
Everything is encrypted in transit over HTTPS. No system is perfectly secure. If we ever discover a breach affecting your information we will tell you without delay, including what we do not yet know.
Everyone else who touches it.
Four, and the privacy policy lists exactly what each one gets. We do not sell your information and we do not share it for advertising.
| Who | What they get |
|---|---|
| Cloudflare | Hosting and delivery of the application and the nightly exports. |
| Neon | The managed Postgres database the product runs on. |
| Stripe | A billing name and email, and payment details entered on Stripe's own pages. Card numbers never reach us. |
| Anthropic | Only when a scheduler types a request in plain English: that sentence, plus the names of your locations and positions, so the words in it can be matched to real places and roles. Your staff list is not sent — a staff name reaches the model only if the scheduler typed it. Nothing is sent unless someone types something. |
The last one is the one to think about, so here it is plainly: the model turns your sentence into a structured instruction — this person, this shift, these days. It does not decide who works. Filling a week is our own rules and arithmetic, with no model anywhere in it, and every change the model proposes is applied by our code afterwards, through the same checks as a change made by hand.
HIPAA, and what we do and don't offer.
We do not currently offer a business associate agreement, and we would rather explain why than let you find out at the end of a procurement.
A BAA covers a vendor that handles protected health information on your behalf. This product is built so that there is none to handle: the inventory above is the whole database, and none of it is about the people you support. Staffing rosters and attendance records are employment information about your workforce.
Whether a workforce-only scheduling system needs a BAA under your policies, your state's rules and your funders' requirements is a question for your own compliance officer, and they should look at the inventory above. If they need something from us in writing to make that determination, ask — support@delegynshift.com — and you will get a straight answer, including "not yet" if that is the answer.
For whoever checks the engineering.
An IT contractor or a security reviewer is the intended reader here.
The staff boundary is a separate set of endpoints, so it cannot leak by omission
The staff-facing part of the product is its own set of endpoints. It does not share the scheduler's endpoints and gate them by role. Every one of them answers questions about a single person and selects only rows assigned to them.
The distinction matters because of how each shape fails. A role check inside a shared endpoint leaks an entire agency's unpublished week the first time someone forgets to write it — and a missing check looks like nothing at all in a code review. An endpoint that can only ever select your own rows cannot leak by omission. There is no line to forget.
Agencies are separated by the same mechanism: every query is filtered by organization, and the platform-owner role is the only one permitted to cross that line.
Passwords are stored as bcrypt hashes, links expire, and office sessions end after 60 minutes
- Passwords are stored as bcrypt hashes and never in a readable form. We cannot tell you your password because we do not have it.
- Invitation and reset links are single-use and expire — invitations after seven days, password resets after an hour — and are stored hashed rather than in the clear, so a copy of the database does not hand somebody a set of working links.
- Changing a password ends every existing session for that account. If someone suspects their login has been used, changing it is the whole remedy.
- Session cookies are HTTP-only and same-site, and marked secure in production, so they are not readable by page scripts and are not sent from another site.
- Office logins time out after 60 minutes of inactivity, with a warning shortly before, and the session is ended on the server rather than just hidden on screen.
The timeout applies to schedulers, administrators and owners — not to staff. That is deliberate. An office computer at a nurses' station is a shared machine showing an entire agency's roster, and 60 minutes is the right answer there. A staff member's phone shows one person's own shifts, and logging them out every hour would mean the person checking whether they work tomorrow at 11pm has to find their password instead.
Backups: three layers, a restore we have run end to end, and a check that stops a table going missing
We have run a full restore end to end. All three of these exist today, and the third one has been rehearsed on a database we wrecked on purpose first.
- Point-in-time recovery on the database itself, with a seven-day window. This covers the ordinary disaster: a bad deployment, a mistake at our end.
- A nightly export, one file per agency, held on separate infrastructure and kept for up to 90 days. One file per agency rather than one file for everything, so restoring your deleted week does not roll back another agency's legitimate work from the same days — and so a copy of your data can be handed to you without exposing anyone else's.
- A restore procedure we have run end to end. The rehearsal deleted a week of shifts and a staff member from a test database and put them back, and it found a genuine ordering bug that would have made a restore fail partway through. That is what a drill is for, and it is why we can say this one works today.
One more thing worth knowing, because it is the failure this kind of system usually has: an automated check compares the backup's table list against the actual database schema, and fails if a table has been added without saying how it belongs to an agency. We run it before a release, so a new feature cannot quietly leave a table out of your backup: the check refuses to pass until somebody has decided where the new table belongs. A completeness check that only passes because somebody remembered to extend it guards nothing.
If you close your account, ask and we will send you an export first. Deletion reaches the backups as those copies age out.
Try it on this week.
Fourteen days, your real schedule, no card. Long enough to build a full week and print it for the wall.
Start a free trialQuestions first? sales@delegynshift.com