Skip to main content

Rosterfy Objects Reference Guide

Streamline workforce administration by aligning custom fields with the thirteen core data objects.

📌 Note: The screenshots and settings shown in this article may not match what you see in your own platform, as Rosterfy is highly customisable. If you need guidance specific to your setup, please contact our support team.

Rosterfy Objects are organised using thirteen core data objects. These objects serve as the underlying structures for different areas of the platform. For example, managing a Volunteer's profile relies on the User object, a calendar entry uses the Event object, and a tracking sheet uses the Event Shift User object.

Each object comes with standard, built-in fields like First Name or Start Time. When you need to collect unique data, you create a Custom Field. The first step is selecting the correct Rosterfy Object, which tells the platform exactly where to attach and display your new field. A common example is placing a T-shirt size field on the User profile.

💡Tip: Administrators can customse public-facing terms across the system using the Terminology module, but the underlying data structure stays the same.


Inherited Properties and Permissions

Every object within the platform automatically carries three system-managed timestamps used frequently in reporting:

  • Created at

  • Updated at

  • Deleted at

Certain standard fields are set up as "system" fields. These are built into the platform and are visible to Admins, but they are locked so they cannot be deleted.

The objects available to you when creating a custom field depend entirely on your Administrator permissions. A Lite Admin only sees the User object. The other twelve data objects are completely hidden from the custom field selection dropdown. Additionally, sub-accounts automatically inherit custom fields from their parent account, keeping your data collection consistent without manual copying.


Rosterfy Objects

The following list breaks down all thirteen data objects available in the platform. Each section defines what the object manages and lists its standard, built-in fields. Depending on your organisation's setup, the exact field names you see in the interface may be customised, but the underlying data they track remains the same.

1. User

Definition: A specific person within your organisation database, whether a volunteer, staff member, paid worker, team leader, or administrator.

Why Choose This: Use this object for permanent details about an individual that stay true across all Events and Shifts. Updating a User field replaces the old answer.

Built-In Fields: Profile details (name, address, date of birth, photo), login credentials, communication preferences, terms acceptance, and global admin ratings.


2. Account

Definition: The top-level organisation record or a subaccount (branch, department, or division) residing beneath it.

Why Choose This: Use this object to manage high-level settings, branding, permissions, or contact details for your main account or subaccounts.

Built-In Fields: Account names, addresses, parent-child subaccount hierarchies, billing contacts, system permissions, and third-party CRM linkages.


3. Event

Definition: The primary scheduling container that houses structural dates, locations, forms, and one or more individual shifts.

Why Choose This: Use this object to set macro-level rules and logistical details for a major project, festival, tournament, or program.

Built-In Fields: Event dates/timezones, venue address, age restrictions, application limits, default form templates, and Expression of Interest (EOI) settings.


4. Event Shift

Definition: A distinct, time-bounded work slot with a set capacity created inside an Event that workforce members apply for directly.

Why Choose This: Use this object to define specific Shift parameters that apply to anyone working that slot.

Built-In Fields: Shift start/end times, capacity thresholds, break durations, Shift-specific location details, geofencing parameters, and custom form overrides.


5. Event Shift User

Definition: The operational record linking a specific User to a specific Event Shift.

Why Choose This: Use this object to record or track a person’s unique attendance, performance, or operational details for one individual Shift.

Built-In Fields: Exact check-in/check-out timestamps, GPS geofence coordinates, break overrides, shift leader flags, rating notes, and payroll cost calculations.


6. Event User

Definition: The macro-level record capturing a Volunteer's relationship to an overall Event, independent of specific Shift commitments.

Why Choose This: Use this object to track details or answers tied to a person's involvement in a whole event rather than a single Shift.

Built-In Fields: Event registration status, Expression of Interest (EOI) submission/cancellation timestamps, and overall post-event feedback.


7. Event User Activity

Definition: Self-logged hours or contributions submitted by a Volunteer for work completed outside of a formally scheduled Shift.

Why Choose This: Use this object when volunteers log ad-hoc work (such as remote prep work, administrative tasks, or flexible hours) that requires admin review.

Built-In Fields: Volunteer-submitted hours, activity descriptions, start/end timestamps, and administrative approval statuses (Pending, Approved, Rejected).


8. Form Specific

Definition: A standalone submission record generated by a form that creates a new historical entry every time it is filled out.

Why Choose This: Use this object when you must preserve a complete historical record of every submission over time without overwriting past entries.

Built-In Fields: Complete submission logs and timestamped response payloads (ideal for incident reports, periodic compliance checks, or recurring expense claims).


9. Payroll Payrun

Definition: A structural batch processing work logs and timesheets for payroll export.

Why Choose This: Use this object to group, review, approve, and export workforce hours to third-party payroll systems.

Built-In Fields: Pay period date cycles, single-Event constraints, subaccount inclusions, timesheet processing rules, and payroll export statuses.


10. Rewards and Recognition Item

Definition: A physical resource, uniform item, piece of equipment, badge, entitlement, or virtual reward managed within the platform.

Why Choose This: Use this object to track stock, sizes, serial numbers, or point values for physical or virtual inventory.

Built-In Fields: Stock quantities, uniform size variants, serial numbers, reward point redemption costs, and distribution rules at shift check-in/out.


11. Role Offer

Definition: A specific position or job profile an organization actively recruits for prior to assigning approved applicants into shifts.

Why Choose This: Use this object to define specialized role requirements, demand modeling, or application criteria for specific jobs.

Built-In Fields: Job titles, recruitment demand parameters (peak shift counts, users per shift), role qualifications, application deadlines, and fee/refund rules.


12. Role Offer User

Definition: An individual applicant's record on a specific Role Offer recruitment pipeline.

Why Choose This: Use this object to track an applicant's evaluation, status, or responses specific to their application for a role.

Built-In Fields: Application status (Applied, Pre-assigned, Confirmed), priority rankings assigned by admins, feedback scores, and waitlist invitation timestamps.


13. Training User

Definition: A record tracking an instance of a completed training module for an external candidate.

Why Choose This: Use this object to record training results for individuals who complete required modules prior to creating a formal Rosterfy user account.

Built-In Fields: Trainee email addresses, unique access tokens, test completion timestamps, and recorded quiz/training scores.

Did this answer your question?