Product fit / Field notes
RosterLab mobile app or a name-search project roster link?
A worker mobile app and a shareable project link answer different access needs. Check the roster source, privacy model and update process first.
If workers ask “Is there an app?”, the real question may be “Can I find the correct shift without asking the supervisor?” RosterLab describes an employee mobile app as part of its staff rostering offer. RosterField provides a project worker link or QR code for a checked publication of an existing Excel roster. The link opens a page where someone can search by name without an individual worker login. Neither route should be evaluated independently of the schedule it actually displays.
For a roster planned in RosterLab, test the mobile experience using that managed schedule and current vendor information. For a roster already approved in a spreadsheet, test whether the project link leads to the right released dates. Do not assume that an app shows a separately prepared workbook, or that a RosterField publication appears in a different product. There is no integration described here.
Walk through a worker’s first visit
Consider a fictional site worker, Priya, who has been told her next swing starts on Monday. If the site enters shifts in a cloud scheduling product, the supervisor should demonstrate how Priya finds that schedule on her phone and what she should do if her entry is wrong. Check any account, installation, connectivity or access requirements with the product as it exists now; a short feature description does not establish every detail.
If the project instead signs off an Excel workbook, an administrator first checks the import in RosterField and publishes the chosen period. The site then distributes the project URL or QR code in an appropriate channel. Priya opens it and searches her name. She should be able to distinguish her result from someone with a similar name, and the status labels should make sense against the project’s own codes. A draft file that has not been published will not become her current project view just because somebody edited it.
Try this with fictional names before using live worker records. Pick a common surname and a status such as travel or leave; ask a person who did not build the workbook to locate the next five days and explain them. If they cannot, fix the source or instructions before release. See the status-code guide for the importance of defining codes.
Understand the link’s privacy trade-off
The project link is a shareable access method, not an individual login for the named worker. Anyone who receives that link can reach the search. A QR code printed on a noticeboard can be photographed, and a URL in a message can be forwarded. Review which details you are comfortable placing in this worker-facing view; do not include sensitive personal notes on the theory that each person sees only their own entry.
An employee app may have a different access arrangement, but do not infer its exact permissions from the words “mobile app.” Ask the vendor to demonstrate its current worker access model for your setting. If your organisation needs individual authenticated access, decide that before selecting a shareable project link. The worker roster sharing guide discusses this choice and its practical consequences.
Compare change communication, not just screens
A viewing route does not guarantee that a worker has seen an update. Imagine the superintendent changes Priya’s Tuesday assignment after she saved a screenshot on Sunday. In the Excel-led path the project owner approves the revised workbook, the publisher imports and checks it, and the new release becomes current at the project link. The screenshot is still old. For material changes, use the site’s established direct communication process as well.
For a schedule managed in RosterLab, test how changes appear to the particular staff member in its current mobile offering and what the site does when a device or connection is unavailable. Avoid equating any screen or alert with confirmation that a worker accepted a change; your actual communication obligations are separate. The version-control guide explains why a single current source is useful but not sufficient on its own.
Write a simple staff instruction
Specify where the project-approved dates come from, how to open the worker view, how to identify the right person, what to do if a date looks wrong, and where to expect urgent notices. If the plan is made in a cloud scheduler, give the worker its tested access route. If the plan is an approved Excel file, use the reviewed RosterField publication and explain the project link’s privacy model. The how-it-works overview shows what happens between spreadsheet and worker view; it does not claim to schedule shifts on Priya’s behalf.
Questions people ask
Do workers need to install an app to check the Excel project roster?
Not for RosterField’s published project link: a person with the URL or QR code can open the worker page and search by name. If shifts are managed in RosterLab instead, test its current mobile access route with the actual staff who will use it. These are separate schedules unless your team manages a separate hand-off.
What if two workers have nearly identical names?
Test both search journeys before publication and check the underlying workbook records and preview with the project owner. Do not ask workers to guess which assignment belongs to them. Give them a named supervisor to contact if the result is ambiguous; do not rely on a name-search page as proof of identity.
