š 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.
When creating a Custom Field in Rosterfy, your first step is selecting its Object. The object determines what record the collected data attaches to, which forms can display the field, and how data history is preserved in your database.
IN THIS ARTICLE:
How to Pick the Right Object
Before selecting an object, ask yourself one key question: What does this answer belong to and how often can the answer be different?
Every object represents a specific answer to this question. Selecting the wrong object creates one of two structural issues in your database:
Too Broad: The field overwrites previous entries whenever a new response is submitted, leaving you with only the most recent answer.
Too Narrow: You repeatedly ask the same person the same question across every shift, making database-wide reporting impossible.
š”Tip: See the Rosterfy Objects Reference Guide article for more information.
System Rules for Form Availability
Choosing an object directly dictates where and how fields function across your forms:
Form Compatibility Rules: When creating a Custom Field, Rosterfy displays a list of forms to add it to. That list is generated based on your chosen object, it only shows forms configured to capture that object. If you pick the wrong object, your target form will not appear in the setup list.
Admin-Only Field Restraints: Six objects (Event, Event Shift, Role Offer, Account, Inventory Item, and Payroll Payrun) are populated directly by administrators on system records and are never offered as public form inputs.
š”Tip: If you only want volunteers to view event or shift details on a form, you do not need a new Custom Field on the User. Existing Event, Shift, and Role Offer field values can be dynamically displayed on user forms as read-only merge variables (such as merging an Event Location onto a Shift Check-In form).
Quick Object Selection Reference
To record details about: | Choose this Object: |
Something true about a person all the time | User
|
A person's involvement in a specific Event
| Event User
|
A person's specific Shift occurrence | Event Shift User
|
Hours/activities logged outside of scheduled Shifts | Event User Activity
|
An answer where full submission history must be kept | Form Specific
|
A person's application for a specific role | Role Offer User
|
External training candidates without a Rosterfy account | Training User
|
An Event record | Event
|
A Shift record | Event Shift
|
A role being recruited for | Role Offer
|
An account or subaccount record | Account
|
A piece of equiment, uniform item, or reward | Rewards and Recognition Item |
A payroll execution batch | Payroll Payrun
|
Collect Data via User Forms (People-Facing Objects)
People-facing objects capture data directly from users via form submissions. Each handles data overwriting and form availability differently:
User
Stores permanent attributes that do not change from event to event, such as t-shirt sizes, dietary requirements, emergency contacts, or qualifications. Each user has one answer per field; updating the field replaces the previous entry. Ask yourself: "Would I want to search my entire database for everyone who answered X?" If yes, choose User. Along with Event, this is one of only two objects whose fields can be hidden from specific admin roles using custom permissions.
Compatible Forms: Registration, Profile, Data Collection, Admin, Anonymous, and Family Member.
Event User
Captures details tied to someone's participation in a whole event rather than a single Shift such as event-specific accreditation, briefing attendance, or accommodation requests. Use this when the same person could genuinely answer differently across two events and you need to preserve both entries.
Compatible Forms: Event Feedback, Expression of Interest (EOI), Cancel EOI, Shift Application, Check-In/Out, Shift Feedback, and User Activities.
Event Shift User
Tracks information specific to a single shift occurrence, such as assigned check-in gates, equipment issued that day, or supervisor shift notes. Choose this if someone completing five shifts should be able to provide five distinct answers.
Compatible Forms: Shift Application, Pre Check-In, Check-In, Check Out, Shift Feedback, and Shift Withdrawal.
Event User Activity
Captures extra details when volunteers log ad-hoc hours or activities completed outside of scheduled shifts.
Compatible Form: This object is compatible exclusively with the User Activities Form.
Role Offer User
Stores information tied directly to a specific role application, such as motivation statements, relevant experience, interview evaluation scores, or decline reasons. Use this when a user applying for two distinct roles should be able to submit different answers for each.
Compatible Forms: Role Offer Application, Accept, Reject, Withdrawal, and Interaction forms.
Form Specific
Creates a brand-new historical record for every submission without ever overwriting previous answers. Choose Form Specific when maintaining a complete audit trail or recurring history is essential, such as for incident reports, expense claims, weekly check-ins, or complaint logs.
Compatible Forms: This object is compatible exclusively with User Data Collection and Administrator forms configured with submission history.
Training User
Captures details from external trainees completing training modules who do not possess a standard Rosterfy user account.
Compatible Forms: This object is compatible exclusively with the Training Registration Form for External Users.
Manage Administrative Records (Admin-Side Objects)
Admin-side objects attach data directly to backend administrative records and cannot be placed on public user forms. They are populated by administrators directly on system records:
Event: Captures macro-level event details such as region, funding stream, internal cost code, or client name. Fields can be restricted by admin permissions.
Event Shift: Tracks properties of the Shift itself, such as zone coverage, required site gear, or internal reference numbers.
š”Tip: "The zone this Shift covers belongs on Event Shift"; "The zone this volunteer was placed in" belongs on Event Shift User.
Role Offer: Stores specifications for the role being recruited, such as reporting lines, pay bands, or requisition numbers. This describes the job itself, not the applicant.
Account: Records organisational metadata across parent accounts and subaccounts, such as region, chapter, franchise number, or billing references.
Rewards and Recognition Item: Tracks physical equipment, uniform stock, and reward incentives including point costs, stock quantities, size variants, storage locations, and distribution rules.
Payroll Payrun: Records financial execution details, such as approval references or finance batch numbers.
Common Configuration Mistakes to Avoid
Building a field on the wrong object can cause lasting data issues. Keep these three common mistakes in mind:
Using 'User' for Shift Answers: Placing a check-in question like "How are you feeling today?" on the User object causes every check-in to overwrite the previous response. By the end of an Event, you only retain one answer per person instead of a full record across all Shifts.
Using 'Event Shift User' for master details: Placing permanent attributes like t-shirt size on a Shift check-in form forces Volunteers to answer the same question on every Shift, while preventing you from running a single database-wide inventory report.
Overlooking History Requirements on Incident Forms: Storing incident reports on the User object overwrites previous submissions. Always use Form Specific when complete historical tracking is required.