Event Information
WHEN
ON DEMAND
RaceDay Scoring supports dynamic time adjustments based on custom criteria, giving you more control over race results.
In this webinar, we’ll cover:
- Time adjustments based on custom question responses – Automatically modify times based on participant data.
- Real-time changes from CheckIn App – Adjust times seamlessly as updates are entered in to the integrated CheckIn App.
- Custom penalties & count-based modifications – Implement rule-based time changes with ease.
This is an ideal session for timers who have events with multiple components and the need to merge data together such as pre-race contests that impact the endurance component of an event.
Summary of Webinar
What this webinar covered
Adjustments refresher (how “adjustments” work today)
Dynamic Adjustments (new feature): what it is + why it exists
Examples / patterns (penalties, credits, progressive bonus tables)
Where to find it and how to configure
Q&A + operational notes (validations, edit history, what not to use it for)
Adjustments refresher (baseline)
Adjustments = time modifications applied to a participant (or team) by adding/subtracting time.
Comprised of:
Count = how many times to apply it
Duration = the time amount applied each time (positive or negative)
Positive duration adds time → penalties
Negative duration subtracts time → credits/bonuses
Can be applied to a specific segment, but commonly applied to the entire race.
Example segment-specific: triathlon bike leg penalty/credit, train crossing credit, etc.
Today, adjustments are typically applied:
manually on the participant record (Scoring Data → Read & Timing Control area)
or via import (CSV) using Participants → Actions → Import Adjustments (based on Registration ID / RDS participant ID + adjustment amount)
Practical tip they mentioned: if you’ll apply the same adjustment repeatedly (e.g., “30 seconds per donut”), set duration once and only change count.
What “Dynamic Adjustments” are
Dynamic Adjustments = a new way to apply adjustments automatically based on existing data fields.
Core idea:
Both Count and Duration can be driven by other fields (custom questions / custom fields / fixed values).
The resulting adjustment updates in real time as those fields change.
Major benefit vs past “computed field” approaches:
You can now affect the actual finish time fields (not just create a separate computed time field).
This matters because key features (like team scoring) don’t operate off custom computed fields the same way.
Where it lives in the UI
Scored Events → Dynamic Adjustments (a new green button under scored events, per the walkthrough)
Add via: “Add Dynamic Adjustment”
You choose:
Count source (fixed number OR pulled from a custom question/field)
Duration source (fixed time OR pulled from a time/duration custom question OR a select-value map)
Segment to apply to (often “entire race”)
Configuration patterns they showed
Pattern A: Variable count + fixed duration
Use case: “Add 2 minutes per missed obstacle”
Count source: custom question/field (numeric) like # missed obstacles
If it’s free-form text, system only uses numeric values (no “one”, must be “1”)
Duration source: fixed time (e.g., +2:00)
Apply to: entire race
Pattern B: Variable count + fixed duration, multiple adjustments
Use case: “Drafting penalties” and “Course violations” tracked separately
Drafting count from question “drafting penalties” → fixed +10:00 each (example)
Add another dynamic adjustment for different violation type with its own fixed time
Allows stacking multiple dynamic adjustment rules
Pattern C: Variable count + fixed negative duration
Use case: “Donut run” credit: subtract 0:30 per donut
Count source: numeric question “# donuts eaten”
Duration source: fixed -0:30
Apply to: entire race
Pattern D: Fixed count (usually 1) + variable duration from a time-formatted field
Use case: “Known penalty/credit per person” entered in the Check-In app
Count source: fixed 1
Duration source: custom question that is a time/duration field
Notes:
Must be time-formatted (open text isn’t supported for duration)
Works well when staff/volunteers enter the exact penalty/credit time per participant
Pattern E: Fixed count (1) + select-field duration mapping (progressive table)
Use case: “Obstacle bonus” where each selection corresponds to a precomputed credit
Count source: fixed 1
Duration source: select field (e.g., “1,2,3,4,5 obstacles completed”)
Map each option to a specific negative time:
1 → -0:30
2 → -1:15
3 → -2:00
4 → -2:45
5 → -3:30
Goal: avoid doing math onsite; the selection auto-applies the right credit.
Operational workflow they emphasized
Dynamic adjustments unlock a “put it in volunteers’ hands” workflow:
Onsite staff uses RaceDay Check-In app to update participant custom fields/questions
Data syncs → RDS → adjustment updates automatically in real time
Things they explicitly said not to use this for
Adjusting early starts / pre-gun chip start handling
Someone asked about using dynamic adjustments for early start reads.
Recommended approach instead: in participant record, enable Accept pre-gun chip start times (don’t try to compute offsets as adjustments).
Editing reads from the Check-In app
Not supported: you cannot edit reads directly in the Check-In app.
Q&A highlights
Maximum value for count?
Not sure in RDS; might be possible via RunSignup validation rules on the custom question.
Important note from Saurin: the Check-In app uses the same validations as registration for those fields—so if RunSignup supports a constraint, it should carry into the Check-In app experience.Can basic participant info be edited in the Check-In app?
Yes. You can configure a Check-In preset/event settings to allow editing participant info (common use: updating corral assignment at check-in).Data action tie-in idea (good hybrid pattern):
They discussed using a data action to automatically set a participant custom field when a condition is met, and then having that custom field drive the dynamic adjustment.
This can create powerful “automatic when conditions occur” workflows without directly manipulating time logic in the data action.