Custom Objects & Sources in Salesforce

Show Items from Multiple Salesforce Objects, including Custom Objects, in the same Calendar

DayBack Calendar allows you to display events from multiple sources simultaneously, ensuring you always have the full context for making decisions. You can also toggle the visibility of these calendar sources to filter your view as needed.

Each place where you record dates about your work becomes a data "source" for the calendar. For example:

• One source might be an events table containing follow-up calls, meetings, etc.
• Another source could be for campaigns and campaign activities.
• You might have another source for your Google calendars, including personal calendars and those shared with you.

You can even have multiple sources from within the same table. For instance, if you have a job due date and a follow-up date in your jobs table, you can create separate sources for each. Additionally, you can segment a table by record type, creating distinct calendars (with different colors) for each record type within a table.

You can view a list of your available sources on the "Calendars" tab in DayBack's left-hand sidebar. Administrators can create new sources in Admin Settings > Sources.

Creating a new source

Follow these steps to create a new Calendar source in DayBack:

1

Access Administrator Settings

• Click on the Settings tab in DayBack's left-hand sidebar.
• Then click on Administrator Settings. (Admins can also access settings by clicking the gear icon beside any calendar.)

2

Navigate to Calendar Sources

• In the left-hand sidebar, you'll see Calendar Sources. Click on Salesforce beneath that.

3

Review Existing Sources

• You may see a list of your existing Salesforce sources. You can click on any of these to see how they've been set up.

4

Add a New Calendar

• To create a new source, click Add New Calendar. Your Source Settings will appear on the right side of the screen.

5

Enter Object Name

• For the Object Name, enter the name of the Salesforce object you'd like to see in DayBack. This is usually singular, like "Task" or "Campaign." For custom objects, you may have used a plural object name.

6

Learn More with "Details"

• At any time, click on Details to learn more about a DayBack setting and access helpful links:

7

Source Name

• Use the Source Name for the user-facing name of this object in DayBack's left-hand sidebar. This is what users will click on to show or hide the source. It doesn't need to match anything in the Salesforce schema.

8

Record Types

• If your table uses Record Types, you can specify one here. If you choose a record type, only items matching that type will show up for this calendar. This allows you to segment a single table into multiple calendars, one for each record type. If you're new to Salesforce record types, you can learn more about them here.

9

Default Event Color

• You can enter a Default Event Color here if there is a color you know you'd like to match. However, you'll also have the opportunity to select a color from a color picker when you see your new source in the Sources list on the calendar. (The gear icon beside the source in the left-hand sidebar reveals the color picker.)

10

Read Only Setting

• Set Read Only to "Yes" if you don't want users to be able to edit these items in DayBack. Note that Salesforce will enforce your editing and security restrictions regardless of what you set here. However, setting this to "Yes" means your users won't think they can edit these items in DayBack, and they won't see enterable fields.

11

Assigning Times

• If the item you're describing only has dates associated with it (not times), set Can you assign times to these events to "No". For example, Tasks in Salesforce only have due dates, not times.

Now that your source is described, you'll see it in the Sources list in DayBack. However, you won't see any items on the calendar for this source until you specify which fields to use for the item's Date, Title, and other necessary details. This is done in the Field Mapping section.

To complete the setup, proceed to the Field Mapping instructions, where you'll find a detailed video and step-by-step guidance to walk you through the process.

How does DayBack decide which source to use for new items?

In the admin settings, under the Calendar Info tab, there is a setting that allows you to specify if a particular source should be the default for creating new events. If this default source isn't currently visible, DayBack will logically select the next visible and editable calendar when you create a new item. For more details, please refer to the section on creating events.

Any special considerations when creating a new source for a custom object?

Adding a custom object to the calendar is similar to adding any of Salesforce's native objects: if your object has a date field, you're good to go. However, there are a few aspects of custom objects that may not be immediately clear, especially if you weren't the one who developed them. Here are some Source Settings to review when mapping your custom object:

Object and Field Names

• Use API Names: When referencing custom objects and fields, use the API name, including the __c suffix.

Can You Assign Times to These Events?

• Date/Time Fields: If the field you've mapped to "Start" is a date/time field, you can choose whether or not to allow times.
• Date Fields: If the custom object uses date fields (instead of date/time), set "Can you assign times..." to "No". Salesforce will sanitize your data by stripping out any times users try to add, but setting this to "No" will prevent confusion by not giving users the option to add times.

Unused Fields

• Mark as Unused: For any DayBack fields that don't exist in your custom objects, simply mark the "unused" checkbox, and DayBack will hide those fields from the popover displaying your object. If you don't see "Unused" beside a field, it is required, and you'll need to find a relevant field in your custom object.

Project Objects

• Project Objects are the possible "parents" of your custom object, but if your object has no parent object, this field does not need to be mapped. Here’s how to determine and configure project objects:
• Determine if Your Custom Object is a Parent or a Child:
  • Parent Object:
    • Is your custom object the "parent" of another object, similar to how a Campaign is the parent of a Task?
    • If so, you don't need to define any Project Objects for it.
  • Child Object:
    • Is your custom object the "child" of another object, similar to how a Task is the child of a Campaign or Case?
    • If so, and your custom object contains a "RelatedTo " field, then it will have parent objects, and you need to map these Project Objects.
• When to map:
  • Your object has a "parent" object
    • If your custom object is more like a Campaign (and is not a child of another object), you don't need to define any Project Objects for it.
    • If your custom object is more like a Task (and could be the child of a Campaign, Case, or another object), you'll need to define the parent objects.
  • Based on desired user interaction
    • Only define parent objects in DayBack if you want users to select or change them within the calendar.
    • If you only want users to see information from the parent, configure the "Related to (What)" field and add the desired information to the "Display" field in the field mapping for your custom object.

For more details on configuring related objects, see the Contact and Project Objects section.