Privacy · Shiftly
A coverage question does not need the whole personnel file.
Shiftly's subject is scheduled work: the role, window, requirement and proposed or assigned adult. This guide separates those scheduling facts from material that has no place in a first product conversation. It describes the site's current scope and questions to settle for a deployment; it does not invent a contract, retention schedule or new consent workflow.
Data & privacy
A shift record holds the role, the time window, the credential requirement, and who is assigned or proposed — employment facts about working adults, not student data. The K-12 sub-coverage skin adds a building assignment and a substitute-credential requirement, still employment facts, not a student roster.
No facial recognition runs anywhere on this product — there is nothing here to match a face to. No automated decision is made about a child: a substitute match is a credential-and-availability check on an adult, never a determination about a student. No AI or machine-learning claim is made anywhere on this page or the rest of the site — matching and self-heal are constraint-based rules, described as exactly that.
Send the rule and its effect, with identities removed
A useful matching example can be small. Describe an open window, the role required and two fictional candidate records. One might have availability that ends too early; another might have a credential date before the scheduled shift. That is enough to discuss why a candidate should be refused. The issuing document, home address and personal reason for a callout do not help explain the comparison and should stay out of the example.
Substitute coverage is still an adult scheduling discussion. A building assignment and a substitute-credential requirement can be described without a child list, class timetable or learning record. Do not attach those records to an introductory email. The early-access skin is not presented as a student-placement system. If a future use case crosses that boundary, it needs a separately reviewed workflow; this page neither designs nor authorizes one.
Reading this site does not create a roster
These pages explain the product and link to an email address. They do not contain a staff-upload form, live assignment action or signup wizard. Clicking the contact address opens your email application; composing and sending the message is your action in that application. Avoid interpreting a navigation click or a worked example as a saved roster, an accepted shift or a confirmed early-access account. None of those actions takes place in the marketing renderer.
A public product page is also not a complete statement of an operator's deployment terms. Ask about the environment you would use, who administers it, what access each role receives and how a support request should be handled. Do not infer a particular hosting location, log lifetime, deletion deadline or audit export from the presence of a privacy page. Those answers need to be settled for the intended service, rather than guessed from promotional copy.
The credential-gate
A shift that requires a credential checks the assignee’s credential expiry and scope against the shift’s requirement before the assignment is offered — the same hard-constraint gate reused from shipped work elsewhere in this fleet.
What it does not do: it does not certify, license, issue, or verify the authenticity of a credential. It checks an expiry date and a scope against a record the school or business already supplies. That determination stays with whatever authority issued the credential in the first place.
Keep the explanation useful without distributing the source record
When reporting a confusing result, start with the required shift window, a general description of the candidate condition and what you expected to happen. Use a synthetic version when possible. A message saying that the supplied expiry is before the shift date is more focused than forwarding a credential document. The distinction also makes the conversation easier to review: everyone can discuss the rule without inheriting unrelated details about a member of staff.
If a screenshot is necessary for an agreed support conversation, remove names, contact information, account links and any unrelated rows before sending it. Do not include credentials used to sign in. State whether the issue concerns a proposal, a response or an assignment, because the remedy depends on which decision has actually occurred. This is guidance for preparing a minimal report, not a claim that this website provides a private upload channel or automatic redaction service.
Settle access and lifecycle questions before operating
Before a pilot becomes routine, ask who owns the scheduling records, which managers may see which teams, how staff corrections are handled and what happens when a person leaves. Ask separately how a record correction affects an existing proposal. A date comparison can be straightforward while the organization's process for maintaining that date remains unresolved. The operational owner should know how to correct an input and how to review the resulting decision.
For procurement or privacy review, bring the actual questions rather than assuming a certification or legal guarantee from the feature list. Shiftly makes no claim to authenticate credential documents or automate a decision about a child. Planned white-label branding does not remove the platform's sending-domain and consent/legal footer boundaries. Contact us with the review you need; getting started keeps the first evaluation narrow enough to discuss those boundaries before a wider rollout.