📌 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 creating a custom field, determine its scope and frequency: Where does this data live, and how often does it need to be collected?
Selecting the wrong object creates one of two structural problems in your database:
Scope Too Broad (Overwriting Data): If you attach Event-specific data to a broader scope (like the User profile), new responses overwrite old ones, leaving you with only the most recent entry and wiping out historical data.
Scope Too Narrow (Redundant Collection): If you attach permanent data to a narrower scope (like a Shift or Application), you force users to answer the exact same question repeatedly, cluttering your forms and breaking global reporting.
💡Tip: See the Rosterfy Objects Reference Guide article for more information.
How Custom Field Objects and Categories Work Together
Custom fields capture your data, while field categories structure how that data is displayed, behaving differently depending on whether you are in the admin portal or filling out a public form:
Objects Define the Base Location: The chosen object determines where the data belongs in your system (e.g., on a User Profile, Event record, or Shift).
In the Admin Portal (Admin-Facing): Certain objects such as Event, Event Shift, Role Offer, Account, Inventory Item, and Payroll Payrun, are designed strictly for administrative record-keeping. They can only be updated by admins and cannot be used as input fields on public forms.
Categorised Fields: Assigning a category automatically builds a dedicated navigation tab within that object’s record view (e.g., an Event record or User Profile).
Uncategorised Fields: Any custom field created without an assigned category defaults to the primary Custom Fields tab on that record.
On Forms (Public-Facing): When configuring a custom field, Rosterfy only shows forms that match your selected object. If a form is missing, it isn't configured for that object type.
Categories group related fields into clean visual sections or multi-step pages, making forms easier for volunteers to read and complete.
💡Tip: See the Create and Update a Custom Field Category article for more information.
Objects for Forms
Only specific object types can be used when adding an object custom field to a form. Ensure you select one of these supported object types during setup so the field displays and functions correctly for users. The following user-facing objects compatible with forms include:
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.
Admin-Only 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. Appears in update account in custom field tab.
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 custom field on the wrong object creates data issues across your system:
Using 'User' for Shift Answers: Placing Shift-level questions (e.g., check-in responses) on the User object overwrites the field with every entry, wiping out your shift history.
Using 'Event Shift User' for Master Details: Placing static attributes (e.g., date of birth) on a Shift form forces volunteers to re-enter data repeatedly and breaks global reporting.
Overlooking History Requirements on Incident Forms: Storing incident reports on the User object overwrites prior incidents. Use Form Specific when you need full historical tracking.
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
|