Custom Configuration for Object Mapping

What is Available Through Custom Configuration Screens?

We are constantly innovating new configuration screens to keep up with customer demand. These screens allow admins to use logic to make changes in their data and view standard logic CaliberMind is using to configure your default system settings. Allowed changes are detailed more below, but at a high level you can:

• Apply global Filters to select the specific data you would like to be present in any of your reports or dashboards. By telling us what you want to keep, you're also telling us what you would like to globally exclude.
• Map custom fields as a replacement for standard fields, often leveraged in reports (like Close Date, Amount, or Type fields).
• Replace a value in a column with another column's value in certain scenarios.
• Substitute inconsistent text values with a standardized set of values.

Because every marketing automation platform and CRM are highly customized, CaliberMind allows for a lot of flexibility. However, we can't accommodate every request in a configuration screen. If you have a customization request that doesn't fit into our current configuration options, please reach out to your customer success representative.

Go Back to the Table of Contents

Before We Dive In

Customization Use Cases

Filters

Filters should only be used when your organization wants to include a limited data set into your CaliberMind instance. These are global inclusion rules that can't be undone at the report or dashboard level.

Common use case examples:

1. My company uses "Test Account" in any account names that we want to exclude from our reports. We use these accounts to log fake activities, people, and opportunities against when we need to test our configuration after we deploy changes from a sandbox. Therefore, we need to tell CaliberMind we want to include any account data that doesn't have "Test Account" in the name.
2. All divisions within our corporation use the same Salesforce instance that we do and admins have access to all data. Our team only should see a subset of opportunity record types to minimize confusion. We are with the Digital Division and only want to see opportunities of Type "Digital."
3. We test our forms all the time and use an email ending with "test.com". We need to tell CaliberMind to only include all person records that do not have an email address that ends with "test.com".
4. People in our company are on our website all the time! We want to only report on records that do not have our domain so that we aren't skewing our numbers.

Go Back to the Table of Contents

Mapping

There are certain fields CaliberMind uses by default, particularly for Salesforce, Marketo, Pardot, and Hubspot users. These include the Opportunity Amount, Type, and Close Date fields; the Account Type, Website, and Status fields; and Contact or Lead email fields. Mapping rules allow you to swap out fields when your organization uses a custom/non-standard field instead.

Common use cases include:

1. We are more concerned with Total ARR than the total contract value on an opportunity. We would like to swap the Total ARR field for the Opportunity Amount standard field in all of our reports.
2. We have multiple close dates on our opportunity, but we only consider the Contract Received Date field as our actual Close Date. We want to swap out the Opportunity Close Date field with our custom Contract Received Date field on all reports and dashboards.
3. Our company has a very niche product that we sell into a single vertical. Instead of focusing on Industry, we'd rather look at a Sub-Industry field that is more specific.
4. A large segment of our business is in the federal space, and people use their personal emails to fill out forms. We want to use the Business Email custom field for all of our reports and dashboards instead of the Email field, which captures the form fill data.

We recommend reading through Where Do I Put My Configuration? before reading our step-by-step help document on Mapping.

Go Back to the Table of Contents

Replacement

A replacement allows you to reference a different field when a certain value is listed in your primary field. Common use cases may include:

1. The Campaign Type field works 90% of the time, but when we see the value "Paid Advertising" we actually would rather sub out the values we store in the "Advertiser" field on the Campaign object like Google, AdRoll, or Bing.
2. We normally rely on Industry field values, but when the Industry value is Computer Software, we need to look at a Sub-Industry field that tells us whether they are Mobile App or Device Agnostic.

We recommend reading through Where Do I Put My Configuration? before reading our step-by-step help document on Replacements.

Go Back to the Table of Contents

Substitutions

Substitutions allow your organization to standardize fields that have inconsistencies.

Common use cases include:

1. Standardizing the Industry field into a smaller subset of agreed-upon values.
2. We want to use titles to see if the title contains text matching a department (like "Marketing," "marketing," "mktg," or "Mktg") to provide a value for the Department field.
3. We want to use the text at the beginning of a campaign name to derive the Campaign Type field values.

We recommend reading through Where Do I Put My Configuration? before reading our step-by-step help document on Substitutions.

Go Back to the Table of Contents

Where Do I Add My Rules?

If you've clicked on the Object Mapping option, you've probably noticed that you have many, many choices.

Before you apply any configuration, you need to understand our data model to a degree. We go into more detail below and provide use cases, but an extremely simplified data flow looks like this:

Think of configuration like this:

• Applying configuration to a parent table (cm_person, cm_event, cm_opportunity, or cm_campaign) will impact the data from all the child tables, not just the data coming in from the CRM (in our cm_person example, it would contain data from the contact and lead objects in your CRM, un-synced person data from your marketing automation platform, and LinkedIn form-fill, and other ad form fills with people that don't exist in your CRM).
• If you want to impact the data coming out of the CRM but want to use logic based on fields that have been cleaned up (like domain, website, or title data), start with the CRM table.
• If you want to impact the raw data before it goes through any cleansing, use the RAW table. The RAW table is only available for Leads.

Go Back to the Table of Contents

Account

Accounts are Accounts or Companies (if you're using Hubspot) as they exist in your CRM without additional data appended to them from the Opportunity (or Deal table if you're using Hubspot) or the CaliberMind Event tables, which include Campaign Member, Task, Event, and Advertising data.

The Account tables are used when you want to apply general geographic or firmographic logic.

At the Parent level (the cm_account table, NOT the cm_account___CRM table), the common use cases are:

Filtering

• Include all but a specific Type field value (you want to include everyone except Investors or Competitors)
• Only look at certain Account Record Types
• Include all Sources except an account Source known to cause duplicate accounts

Mapping

• Swap out a custom field "Department" for the Source field

Replacements

• Group multiple account Source values into a single bucketed group Source

Substitutions

• Change "Source Title" from a long string to a user-friendly name
• Adjust an account name with a typo

When do I use the CRM table?

The raw CRM table is the "child" of the cm_account table. Any changes made to the child table will roll up to the parent. We suggest that logic-intensive configuration be applied to the parent or cm_account table. Common use cases include:

Filtering:

• View all accounts except your own company
• Only view specific Business units
• View all accounts except Partner Accounts

Replacements:

• Use a Custom Name field for accounts that have the text "Parent" in their standard Name field

Substitutions:

• Change account names to include a standard format (example: CreatedDate_AccountName_Type)
• Group Business Units field values into a standardized Business Unit value

Go Back to the Table of Contents

Campaign

cm_campaign is the parent table that houses all campaign information from multiple sources. Child tables may include data from your CRM or marketing automation platform, Google Ads, LinkedIn, Facebook, or any other advertising platform. Use the parent table to impact field values coming from all data sources.

Common use cases include:

Filtering

• Include all except non-inbound campaign types
• Include any campaign type that isn't an operational campaigns

Replacements

• Using a custom Campaign Name field for a subset of Campaign Types
• Replace a subset of utm_source values with a custom field value

Substitutions

• Group multiple campaigns together in a custom Campaign Type
• Assign multiple campaigns to a Program

When do I use the CRM table?

The cm_campaign__CRM table is a child table to the cm_campaign table. Use the child table when you only want to impact the logic applied to your CRM campaign data. This information will roll up into the parent account, but will not be applied to other child tables such as LinkedIn or Facebook.

Common use cases include:

Filters

• Include all except operational campaigns only logged in your CRM
• Include all except a couple problematic campaigns (ex: primarily contain "fake" people from bot form fills)

Replacement

• Use a custom field for a subset of Campaign Types
• Change the Campaign Type to Newsletter if Campaign Name contains "Newsletter"

Substitutions

• Find campaigns with Campaign Type containing “Digital” or “Ads” and grouping under a new Campaign Type of “Programmatic”
• Grouping multiple trade show campaigns under a single umbrella

Go Back to the Table of Contents

Company

The cm_company table is the parent of cm_account and contains not only summary data from opportunities but also lead "accounts" for leads that can't be matched to an existing account record. If you want to use aggregate data from opportunities or include lead accounts in your configuration logic, use the cm_company table over any of the Account tables above.

Common use cases:

Filtering

• Include all accounts except partner companies
• Include all but internal "companies" from accounts and lead form fills

Replacements

• Use a custom company name field for a subset of accounts
• When someone has a title, replace the value in a certain field

Substitutions

• Group multiple company branches together under a single Business Type
• Use aggregate opportunity data to create a "Customer" type

Go Back to the Table of Contents

Event

The cm_event table is the parent table for all of your activity sources and contains both Inbound (scored) and Outbound activities. Common use cases include:

Filtering

• Include all except some types of events (such as email opens)
• Include all events except operational events

Replacements

• Point to a custom field for Campaign Type when the original Campaign Type is Trade Show
• Point to a different Event Name field in some cases

Substitutions

• Group certain events into Categories
• Group multiple newsletters into a single Newsletter Campaign Type, otherwise use the standard Campaign Type value

Go Back to the Table of Contents

Lead

Leads are person records that aren't mapped to an account. They may exist as a lead because your automation process can't match them to an account record and convert them, or perhaps your default object upon form fill is Lead. It should be noted that the cm_lead table is the parent table and houses lead records that may not be in your CRM (for example, they filled out a LinkedIn form, but were never created in Salesforce). There is a RAW table that reflects the data exactly as it is in your CRM. Then there is a table between the parent and raw table that has some title cleansing and domain cleansing already applied.

Common use cases for the cm_lead parent table:

Filters

• Include all but poorly qualified leads
• Include everyone except internal stakeholders

Replacements

• Change the Website field to point to a custom field when there are certain characters in the original field
• Replace the standard Title field with a custom Title field

Substitutions

• Use title text to approximate the department
• Group discreet sources into Source Types
• Transform granular industries into a clean Industry value

When do I use the Salesforce/CRM table?

You would use the middle-layer lead table if you only want to change CRM records, but need to base the logic on cleansed email or domain data.

Filters

• Include everyone without your company's domain
• Include everyone except specific titles (Student, Pastor, Janitor, etc.)
• Include every Form Reason except "Job Hunting"

Replacements

• Update the industry of a lead with a custom field value
• Adjust the Title values with a normalized field

Substitutions

• Apply logic to reduce a raw Industry field into a standardized subset of values
• Combine several leads with certain characteristics into a single Type

When do I use the RAW table?

You would use this table if you only want to change CRM records and need to apply some custom logic prior to the cleansing unification process.

Filters

• Include all except some companies
• Include all except a subset of industries

Mapping

• Swap out a custom field for Website
• Swap out a custom field for Title
• Swap out a custom field for Email

Replacements

• Change the website with a new field value in a subset of cases
• Adjust the industry with a new field in a subset of cases

Substitutions

• Use text-based logic to standardize industries
• Use text-based logic to create a company Group

Go Back to the Table of Contents

Opportunity

Cm_opportunity_CRM will contain all of the transformed raw data from your CRM instance and the cm_opportunity table is a roll-up of multiple potential source tables (your CRM, Facebook, Linkedin, and Google Ads). If you want to change every child table, we recommend applying the logic at the parent table level.

Filtering

• Include all except Closed Lost opportunities (this will impact win rates!)
• Include opportunities created after a specific date

Replacements

• Update the Weighted Amount for certain probabilities to a custom field value
• Adjust old product names to the new price book's names

Substitutions

• Group Opportunity Type values of New - Client and New - Subscription into a new consolidated type of New Business
• Group territories into Region values

When do I use the CRM table?

The CRM opportunity table is a child table that rolls up to cm_opportunity. If you want to change just to the salesforce data, then we suggest using the CRM table.

Filters

• Include only some record types
• Include all opportunities except those related to a different business unit

Mapping

• Change Amount to a custom field (ex. Total ARR)
• Change Lead Source to Source Department or some other custom field

Replacements

• Change the probability associated with certain opportunity Stage values
• Update older opportunity Stage values to newer values

Substitutions

• Group multiple sales territories into a Region
• Group several Types into a single Opportunity Type

Go Back to the Table of Contents

Person

The cm_person table is a combination of your CRM's contact and lead tables, along with other child sources. Apply configuration logic to this parent table if you want the logic consistent across all of your sources.

Common use cases include:

Filtering

• Only include leads that have a matched account
• Include leads that do not have certain Job Levels

Replacements

• Change the Department field to a custom field value
• Adjust job_level to a custom field in a subset of cases

Substitutions

• Use text-based logic to group multiple department values together into a Department category
• Use text-based logic to standardize the title (for example, if the field contains "MNGR" "mng" or "mng", standardize the value to "Manager")

When do I use the CRM table?

Use the cm_person___[CRMname] table when you would like to only apply configuration logic to your Contact table in Salesforce/Dynamics (or Person table in Hubspot).

Common use cases include:

Filtering

• Only include contacts with an account (non-orphans)
• Include all but certain Job Levels just from Contacts

Replacements

• Change the Department field to a custom field value
• Adjust job_level to a custom field in a subset of cases

Substitutions

• Use text-based logic to group multiple department values together into a Department category
• Use text-based logic to standardize the title (for example, if the field contains "MNGR" "mng" or "mng", standardize the value to "Manager")

Go Back to the Table of Contents

How to Set Up a Filter

How to Set Up a Mapping

How to Set Up a Replacement

How to Set Up a Substitution

Go Back to the Table of Contents