Working with Custom Fields in App Actions

When you tell DayBack about the objects and tables that contain your event data, you can also tell DayBack about your most important custom fields. This is accomplished through field mapping which defines how your database fields are exposed to DayBack as Custom Fields.

This article explains how to access and modify you events' Custom Field values once they've been defined in your field mapping. The techniques outlined below work consistently across Salesforce, FileMaker, Google, and O365 deployments.

Where to Define Custom Fields

Custom Fields can be defined under the "Custom Fields" tab of the settings section of each individual calendar. To learn more about each configuration setting, check out our article on custom fields.

Accessing Custom Fields using JavaScript

For every Custom Field that you define, DayBack will assign your field a numerical ID, referred to as the ID for Calendar Actions. This numerical ID will look like 1758647041519-9040647878 . The screenshot below illustrates how the ID will appear for each of your custom field definitions:

Once your Custom Fields are defined, your JavaScript Event Action and Button Action will now be able access your Custom Fields  by accessing them directly through the event and editEvent objects.

Accessing Standard Fields

DayBack's standard fields can be accessed directly as follows:

event.title = 'Title';
event.description = 'Description';
event.resource = [ 'John Smith', 'Jane Smith']

Learn more about all available standard fields in your event object.

Accessing Custom Fields

Custom fields need to be accessed using their numerical IDs (ID for Calendar Actions). For example, to change the Visit Type field to a 'Follow-Up', you can access it as follows:

// Visit Type Custom field
event['1758647041519-9040647878'] = 'Follow-Up';

Accessing Fields by their Field Name

Although accessing custom fields by their numerical ID is the fastest method, it can make your JavaScript code harder to read and maintain. For this reason, it’s generally better to reference fields by a human-readable name in your code.

Each custom field has a Label, which controls how the field appears in the DayBack popover, and a Store in Field value, which represents the actual field name in your underlying database—such as Salesforce, FileMaker, or Google Calendar. For example, a field labeled Visit Type in Salesforce is stored using the field name Visit_Type__c .

DayBack provides the dbk.getCustomFieldIdByName()  helper function, which lets you retrieve a field’s numerical ID using its database-level field name. Once you have the ID, you can use it to read from or write to the custom field.

The function accepts two parameters:

• Store in Field name — A string containing the database field name (for example, Visit_Type__c ).
• event.schedule  object — The calendar configuration object that contains your custom field definitions.

The example below shows how to retrieve the ID for the Visit_Type__c  field and then use it in a custom action:

// Retrieve numerical ID for truckNumber
const customFieldId = dbk.getCustomFieldIdByName('Visit_Type__c', event.schedule);

// Retrieve the Visit Type by its field ID
const visitType = event[customFieldId];

// Set Truck Number using the field's ID
event[visitType] = "Follow-up";

Advanced Methods for Accessing Custom Fields

While the general approach mentioned above can work well if you only have to manage a few fields, your code can quickly become verbose and hard to read when working with a large amount of custom fields.

To make your code even more human-readable, DayBack provides an additional helper function. The dbk.resolveCustomFields()   helper function provides a higher-level, developer-friendly alternative that allows you to work with human-readable custom field names directly, while still ensuring DayBack receives data in the correct internal format.

What dbk.resolveCustomFields() does

dbk.resolveCustomFields()   returns a proxy-backed object that transparently maps:

• Internal custom field IDs → friendly field names (when reading)
• Friendly field names → internal IDs (when writing)

This works for:

• Event objects (event  , editEvent  )
• Change/update objects (changesObject  , updates passed to updateEvent()   or createEvent()  )

Basic usage

At the start of your Custom Action, resolve the event objects you plan to work with:

const _event = dbk.resolveCustomFields({ event }); 
const _editEvent = dbk.resolveCustomFields({ event: editEvent });

You can now read and write custom fields directly by their Store in Field name, or by their Label name. For Salesforce, the Store in Field name is also the Salesforce Field Name which always ends with __c  .

// Access fields by Store in Field Name

_editEvent.Patient_Name__c = "John Doe";
_editEvent.Procedure_Name__c = "MRI";
_editEvent.Chief_Complaint__c = "Knee Injury";
_editEvent.Signed_Informed_Consent__c = true;

// Alternatively, access fields by their Label

_editEvent['Patient Name'] = "John Doe";
_editEvent['Procedure Name'] = "MRI";
_editEvent['Chief Complaint'] = "Knee Injury";
_editEvent['Signed Informed Consent'] = true;

Working with changesObject   in On Event Save Actions

When handling On Event Save actions, DayBack provides a changesObject   that contains only modified fields. You can resolve this object as well, allowing you to read, modify, or delete custom fields using friendly names.

When working with a changesObject  you must pass the changes   object along with the related schedule  object, so that DayBack knows how to resolve the object's custom fields:

const _resolvedChanges = dbk.resolveCustomFields({
  changes: changesObject,
  schedule: _event.schedule
});

if (_resolvedChanges.Room_Number__c) {
  // Respond to a change in Room_Number__c field.
}

Removing fields by name

You can prevent specific fields from being updated by deleting them—by field name—in your On Event Save action before DayBack updates the record. This is especially useful when working with formula fields. In some cases, you may want to display a formula field in the DayBack popover but avoid writing to that field when an event is saved. For example:

if (_resolvedChanges.Is_Patient_Under_18__c == true) {
   // This field is a formula field calculated from 
   // the Patient's Date of Birth. We display it as
   // a checkbox in the UI for convenience.
   //
   // However, we do not want to allow users to
   // change this field directly, so we remove it
   
   delete _resolvedChanges.Is_Patient_Under_18__c;
}

Creating or updating events

When creating or updating events from your custom actions, DayBack APIs require custom fields to be keyed by their internal IDs. dbk.resolveCustomFields()   handles this automatically when resolving a  newly-creatednewEvent  or updates   object. Once your object is resolved, it can be safely passed to dbk.updateEvent()   or dbk.createEvent()  as follows:

const _event = dbk.resolveCustomFields({ event });

const updates = {
  title: "Updated Event Title",
  resource: ["resource_123"],
  Truck_Number__c: "Truck Number 1",
  Is_Hazmat_Flag__c: true
};

const _resolvedUpdates = dbk.resolveCustomFields({
  changes: updates,
  schedule: _event.schedule
});

// Friendly access still works, so you can add fields after
// you've initially resolved the changes object.
_resolvedUpdates.Route_Notes__c = "Deliver before noon";

// Since the underlying object stores fields as internal IDs
// this makes it safe to pass a resolvedChanges object
// to native DayBack functions, like dbk.updateEvent().
dbk.updateEvent(
  event,
  _resolvedUpdates,
  null,
  null,
  { isCustomAction: true }
); 

When should I use this?

Use dbk.resolveCustomFields()   when:

• Your action uses multiple custom fields
• You want to avoid repeated ID lookups
• Code readability and maintainability matter
• You are creating shared or long-lived custom actions

You can continue using direct numerical ID field access or dbk.getCustomFieldIdByName()   for simple cases — but for most real-world logic, dbk.resolveCustomFields()   is the more user-friendly and recommended approach.

Recommended Coding Practices

When working with JavaScript in code editors such as Visual Studio Code, the editor may confuse DayBack’s event   object with the native JavaScript Event   object. This can result in JSDoc warnings when you access event properties.

To avoid these warnings, a helpful approach is to pass your event   and editEvent   objects into a custom function after resolving their custom fields. For example:

function run() {
  const _event = dbk.resolveCustomFields({ event });
  const _editEvent = dbk.resolveCustomFields({ event: editEvent });

  processEvent(_event, _editEvent);

  function processEvent(event, editEvent) {
    // All your custom fields are available by friendly name here,
    // and do not trigger JSDoc editor warnings.

    if (event.Truck_Number__c) {
      editEvent.Truck_Number__c = "Truck Number 1";
    }
  }
}

With this pattern, accessing properties on the event   objects inside your function will no longer trigger JSDoc warnings in your editor.

That said, while this approach allows you to keep the variable names event   and editEvent   unchanged inside the function, we recommend clearly distinguishing between resolved and unresolved objects as you work with proxied objects. A simple and effective convention is to prefix resolved objects with an underscore (_  ).

// Refer to event, and editEvent as you would
// normally:

event.title = "Board Meeting";
editEvent.location = "Conference Room A";

// Refer to a resolved version of these objects
// by naming your objects with an "_" prefix:

const _event = dbk.resolveCustomFields({event});
const _editEvent = dbk.resolveCustomFields({event: editEvent});

_event.title = "Board Meeting";
_editEvent.location = "Conference Room A";

Explore the JavaScript objects and methods you can utilize in your custom actions at Objects and Methods for Custom Actions.

Custom actions provide an excellent environment for experimenting with new code and testing queries. For example, check out how DayBack's Jason Young uses custom actions to console log query results in Testing SOQL Queries in DayBack Calendar.

For testing App Actions or Event Actions, we recommend using Draft Mode. This mode allows you to make custom changes that are only active for your user session. This mode is great for testing code changes without affecting other users. Drafts and be saved, disabled, reenabled, and then applied to production when your code changes are ready for production user.