All Collections
[KBU2024] Integrations
Salesforce to Baton Structure
Salesforce to Baton Structure
Updated over a week ago

Overview

This article is an expansion of our basic Salesforce and Baton integration. It's meant to review multiple Salesforce layouts and how each works for Baton. This is meant to be read after establishing the initial link between Salesforce and Baton. If you have not done that, please refer to this article first.

We support mapping to native and custom objects directly, all Salesforce instances can integrate with Baton. We can pass information to and from not only objects that are 1:1 with Baton projects but also to and from objects related to the object associated with Baton projects. In this article, we'll go over three scenarios in increasing complexity:

  • One opportunity in Salesforce maps directly to one Project in Baton

  • One opportunity in Salesforce requires many implementations. Each of which directly to one Project in Baton

  • One opportunity in Salesforce requires many implementations. Some of which directly to one Project in Baton, some of which are done together in a combined Project in Baton

Note: All of the above are possible for custom object setups not related to Opportunities as well. Baton can handle completely custom schema. We use Opportunity as a base example in the sections below.


One opportunity in Salesforce maps directly to one Project in Baton

Natively in Salesforce, the Opportunity object maps to a sale or renewal. Baton is set up to initially map one Project to one Opportunity set to Closed Won. You can also pull in information from the Account, such as client name. This is mapped below

You notice the three lines into Opportunity. This shows that each Opportunity can be mapped in Baton and a few can inherit the same traits from an Account. If you don't want to import all Opportunities that are Closed Won, you can adjust the Stage in the Baton Salesforce UI. By default, you can adjust the Type and Stage, but you can also add other criteria that is in a checklist form. This can be a manual checklist or a calculated one in Salesforce.


One opportunity in Salesforce requires many implementations. Each of which directly to one Project in Baton

Some Opportunities won will result in multiple implementations. This can be handled in Baton. A common example is if the purchased software applies to multiple buildings or teams that are under the same client but independent of each other. Each may require its own implementation. If a few are worked on as a group, please refer to the next section for how to handle that case. The below mapping shows how you would connect this in Salesforce initially. We call each independent group "Implementation".

In Baton, you would set up your integration to not key off of Opportunity but rather the custom object Implementation. In the example above, Implementation is an object with a Lookup relationship to Opportunity. Alternatively, you could choose a Master-Detail relationship for a similar effect. You'll notice the three lines into Opportunity and Implementation. This means multiple Implementations can map to one Opportunity, and multiple Opportunities can map to one Account. Implementations can import their linked Opportunity and Account information, such as Client Lead Email, for each Project in Baton associated with an Implementation.

As this is a custom object, you don't need to specify Stage or Type for import logic, but you do have to have some criteria. If you want to import all new Implementations, you can simply create a checkbox object set to True on Opportunities like below:


One opportunity in Salesforce requires many implementations. Some of which directly to one Project in Baton, some of which are done together in a combined Project in Baton

Some Opportunities won will result in multiple implementations. This can be handled in Baton. A complex example is if the purchased software applies to multiple buildings or teams that are under the same client but some are worked on together, where others are split out for their own implementations. The below mapping shows how you would connect this in Salesforce. We call each independent group of teams or buildings that map to a Baton Project "Implementation". We use "Building" in the mapping example:

In Baton, you would set up your integration to not key off of Opportunity but rather the custom object Implementation. In the example above, Implementation is an object with a Lookup relationship to Opportunity. Alternatively, you could choose a Master-Detail relationship for a similar effect. In addition, Building has a similar relationship with Implementation. This is so you can map multiple Buildings back to a single Implementation, which is mapped to a single Baton Project. You'll notice the three lines into Opportunity, Implementation, and Building. This means multiple Buildings can map to one Implementation, multiple Implementations can map to one Opportunity, and multiple Opportunities can map to one Account. Implementations can import their linked Opportunity and Account information, such as Client Lead Email, for each Project in Baton associated with an Implementation.

As this is a custom object, you don't need to specify Stage or Type for import logic, but you do have to have some criteria. If you want to import all new Implementations, you can simply create a checkbox object set to True on Opportunities like below:


Did this answer your question?