Custom Objects & Sources
How can I show items from multiple objects, and my own custom objects, in the same calendar?
DayBack Calendar can show events from multiple sources at the same time so that you're always making decisions in context. And you can choose to show and hide these sources as a way to filter your view.
Each place where you record dates about your work becomes a "source" for the calendar. In this way you might have one source be an events table holding things like followup calls, meetings, etc. And have a second source for campaigns, and likely another for campaign activities. Another source would be your Google calendars--both your personal calendars and those calendars that have been shared with you
You can even have multiple sources from within the same table: if, for instance, you had a job due date in your jobs table and a followup date in your jobs table, you'd create those as two separate sources. You can also segment a table by record type, creating one distinct calendar (and color) for each record type within a table.
You can see 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.
In this article
Creating a new source
Follow these steps to create a new Calendar source in DayBack:
- Click on the Settings tab in DayBack's left hand sidebar and then click on Administrator Settings
- You'll see "Calendar Sources" in the left hand sidebar: click on "Salesforce" beneath that.
- 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:
- To create your new source click "Add New Source" and you'll see your Source Settings in the right side of the screen.
- 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" though for custom objects you may have used a plural object name.
- At any time click on "Details" to learn more about a DayBack setting and get helpful links:
- 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. This doesn't need to match anything in Salesforce schema.
- If your table uses Record Types you can specific one here. If you choose a record type here then only items matching that type will show up for this calendar: this lets you segment a single table into multiple calendars: one for each record type. If you're new to Salesforce record types you can brush up here.
- You can enter a Default event color here if there is a color you know you'd like to match, but you'll have an opportunity to select a color from a color picker when you see your new source in the Sources list back on the calendar. (The little gear beside the source in the lefthand sidebar reveals the color picker.)
- 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. But setting this to "Yes" will mean your users won't think they can edit these items in DayBack: they won't see enterable fields, for example.
- If you know that the item you're describing only has dates associated with it (not times), then 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, but you won't see any items on the calendar for this source until you tell DayBack which fields to use for the item's Date, Title, etc. You'll do that in Field Mapping.
Go to Field Mapping instructions.
How does DayBack decide which source to use for a new items?
The gear icon beside a source in the calendars sidebar lets you indicate if this source should be the default for creating new events. If this source isn't currently showing, the calendar will try to be logical if that source isn't currently showing when you create a new items:
You can read more about that here: creating events.
Any special considerations when creating a new source for a custom object?
Adding a custom object to the calendar is the same as adding any of the Salesforce native objects: if your object has a date field, you're in business. However, there are a few things about the object that may not be as clear to you, especially if you're not the person who developed it to begin with. Here are a couple Source Settings to review as you're mapping your custom object:
- Object and field names
- Use the API name when referencing custom objects and fields, e.g. include the __c.
- Can you assign times to these events
- If the field you've mapped to "Start" as the start date of the custom object is a date/time field then you have a choice about allowing times or not.
- If the custom object uses date fields (instead of date/time) you'll want to set 'Can you assign times..." to "No". Note that Salesforce will sanitize your data in either case, stripping out the times users try to add, but it will be less confusing for your users if you don't give them the option of adding times: that's what this setting does.
- For some objects you may not have many of the fields that you see in DayBack under Edit Source Settings. Don't worry; for any fields you don't have simply mark the "unused" checkbox and DayBack will hide those fields from the popover that displays your object. If you don't see "Unused" beside an item then that item 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. In the case of Campaigns, for example, the Campaign is an object in its own right and it is a parent to Tasks: that is, there are tasks related to a Campaign. Campaigns in DayBack are not configured to have parent objects: they are parent objects to Tasks.
- So when you're setting up your custom object decide if it is more like a Campaign (and is the child of nothing) or is more like a Task (and could be the child of a Campaign, Case, or some other object). If it's more like a Campaign then you don't need to define any Project Objects for it. One way to make this decision is if your custom object contains a field for "RelatedTo": if it does, then it will have parent objects.
- Note that you only need define parent objects in DayBack if you want users to select or change them from within the calendar. If you only want them to see the parent, then simply configure the "Related to (What)" and "Display As" field for your custom object in field mapping. More here: contact and project objects.