Data Handoffs

Roster keeps the day-to-day rostering work in one place, then hands data to other tools only at clear points. Think of these as controlled handoffs: sign-in, roster updates, staff messages, check-ins, photos, exports, maps, and future imports from systems D2C already uses.

Transfer Boundaries

The first boundary is sign-in: user identity and role decide which protected areas someone can enter, and staff only see their own roster work. The second boundary is the roster update itself. Campaigns, stores, staff records, shifts, invitations, direct assignments, availability, briefing links, equipment records, reports, and check-ins move through product actions rather than direct spreadsheet edits, which keeps ownership and validation consistent. Staff messages form another boundary because invites, assignments, nudges, cancellations, and response alerts are saved as message records before delivery is attempted; the rostering action still succeeds if email is unavailable. Check-in location is a separate staff-triggered handoff: the browser asks permission, sends one latitude/longitude fix, and stores it against the assignment. Photo uploads are limited to authenticated staff actions with file type and size controls. Report exports re-check admin access before producing client-ready summaries or operational CSVs. Scheduled retries are separated from the original roster action so operations is not blocked by a temporary email issue.

Notification outbox screenshotShows sent, skipped, failed, and retried message states when provider configuration is final.

Data export screenshotShows the admin export endpoint or download flow used for ERP, CRM, payroll, or finance review.

Data Sources Today

Today the product runs from a small set of sources. Sample data provides the Bulla/Woolworths and Cobram-style campaign scenarios, geocoded stores, geocoded staff, skills, availability windows, coverage states, check-in examples, reports, and briefing links used for review. The roster database is the main operating record for campaigns, stores, staff profiles, shifts, assignments, staff responses, check-ins, reports, equipment, and message history. The email provider is optional until sender settings are available. Photo storage is optional too; report photo fields can stay hidden until it is configured. Browser forms and staff device actions are the primary input surfaces, which means admin and staff activity is captured as structured entries rather than scattered chat history.

Integration Surface

The first production version should keep integrations narrow. Each connected system should have an agreed owner, a clear direction of travel, and a fallback if access is delayed.

Staff lists should connect to HR, payroll, or an internal staff master file, but the first step should be import and duplicate review rather than live two-way sync. Store and location lists should start read-only from retailer, territory, or route-planning data, with operations able to override names and locations when field reality differs. Messaging should begin with email before SMS or WhatsApp, and every sent, skipped, or failed message should remain visible so operations can follow up manually. Photos and briefing files should attach to the campaign or shift where staff need them, protected by simple access checks. Payroll and finance should receive reviewed completed work as an export first, then move to a direct integration once hourly rates, timesheet rules, and approval ownership are stable. CRM and client reporting should receive clean report summaries only after the internal campaign record is trusted.

Migration Posture

D2C may already have internal tools, spreadsheets, scripts, ERP modules, CRM records, finance exports, or reporting dashboards that work well enough in parts of the operation. The roster app should not assume those systems disappear on day one. The integration posture is piecemeal migration with visible ownership, not a big-bang replacement.

Each existing tool should be assessed before it is replaced:

• Keep it if the workflow is trusted, has an accountable owner, and only needs roster data as an export or reference.
• Wrap it if D2C still depends on it but the user experience or data shape is inconsistent; the roster app can provide cleaner intake, validation, or export around it.
• Migrate it if the tool duplicates core roster truth such as shifts, staff responses, assignments, availability, reports, or check-ins.
• Rebuild it if the current tool blocks operations, lacks a usable data model, has no owner, or cannot support the fields needed for campaign work.

The first migration step should be a system inventory: what data each tool owns, who edits it, who consumes it, how often it changes, and what breaks if the system is unavailable. From there, D2C can choose one source of truth for each record type. For example, staff contact details may stay in an HR/payroll source while roster availability lives in this app; CRM may own client/account context while the roster app owns campaign shifts and field reports; finance may own final payroll while this app exports reviewed shift evidence.

During migration, dual-running is acceptable as long as the boundary is explicit. Imports should be idempotent where possible, external identifiers should be stored beside roster records, and exports should include enough metadata for reconciliation. The app should prefer one-way imports, reviewed exports, and manual override screens before live bidirectional sync. That keeps D2C operating while the team decides which existing tools are correct to keep, which should be wrapped, and which should be retired.

Future Data Sources

Later, D2C should add a staff master list or HR system to reduce duplicate staff records and stale contact details. Store and location master data would improve geocoding, retailer naming, directions, nearby-staff maps, and route planning, but it should still allow manual override. Payroll or finance integration can start from the current payroll CSV, then mature once rate, approval, overtime, and award-rule ownership is stable. A client CRM can connect campaigns and reports back to account ownership once the internal campaign model has stabilised; the current JSON export is the first simple handoff for that broader integration. Briefing file storage should give staff the right files at shift level, ideally with access logging. Equipment should eventually connect to inventory or kit ownership if D2C needs to track handoff and return, not just name the gear required by a shift.

Design Principle

Every handoff should degrade gracefully. Rostering should still work if email is not configured; reports should still work without photos; directions should still fall back to an address or store name when coordinates are missing; distance ranking should skip records without coordinates; check-in should fail clearly if a staffer denies location permission; and CSV exports should still be available before a full client dashboard exists.