Thinking Ahead: Integration

Before mapping a lifecycle, you need to understand how your customer will integrate with Chassi. Will you be using Single Customer View and have Chassi manage your Contacts and Customers, or do you just need to reference your customer that is being managed in an external system? Perhaps both?

Parts of the Integration

Using Customer Lifecycle in Chassi consists of just a few key elements.

• The Lifecycle you create through the Process Map.
• The Application Space a Lifecycle Version is published in.
• The Journey you start for the Lifecycle.
• The Entity(s) you place on the Journey.

A Lifecycle is the business process that you define, and the Journey is the path that your Entity takes through the lifecycle.

Lifecycle and Journey are pretty straight forward, however, the Entity is more ambiguous because it can be anything that you want to track on a Journey. The Entity can be a reference to your customer that is being managed by Chassi or to your customer that is managed in a external system like Salesforce or within your database. In some cases, you might want the same customer to exist in Chassi's Single Customer View product as well as your external/internal customer management system. In any case, we can support all of these use cases.

An Entity link is established in the Journey as a Chassi Entity Data Type or an External Entity Data Type that you provide. You can link one, both or many of either, it's up to you.

An Entity can also be something other than a customer that you are interested in tracking its lifecycle, such as a contact or other type of resource, like a Word document, form completion or a monitoring an account balance. With the External Entity Data Type, you can specify any custom entity type that exists in your application or system of record, allowing you to create Journeys for absolutely anything.

Example Use Case

The most common type of integration with Chassi is one where you will want to reference the customer, contact or other types of Entities in your private system or a system like Salesforce. Many Chassi customers also prefer to use the Single Customer View, either to provide an interface to inspect their integration or to allow customer service agents to access their customer's record through Chassi's dashboard.

To do this, you need to be able to reference the Chassi IDs for "Customer" while at the same time maintaining the integration and referencing the customer as it exists in your other system's database. Referencing the IDs for both the Chassi "Customer" and whatever your notion is of the customer in other systems allows you to directly query and analyze the customer information with those links intact.

For example, you may not know what the Chassi "Customer" ID is for the Entity, but you will probably know your database ID in whatever source the customer exists on your side. This improves the understanding of the data and integration, but also allows you to improve the quality of searches and reports because you can analyze the data in the context of your other data silos.

If you have no need to use Chassi's "Customer" or "Contact" in Single Customer View, then you don't have to use it. This allows you to create Journeys solely based on your database and Entities and Chassi doesn't even have to manage the complete record of your Entity.

Mapping the Entity Type

There are two different Entity Type declarations for a Journey. One is for Chassi well-known Entities, and the other is for any Entity that you want to define externally from Chassi.

• EntityArray / EntityType: These are Chassi provided Entity Data Types. Entities linked here are resources with a system of record in Chassi.
• ExternalEntityArray / ExternalEntityType: These are custom Entity Data Types defined by you. Entities linked here are resources with a system of record outside of Chassi, such as your database, Salesforce or other remote data stores.

A Journey supports a one to many relationships to Entity Type and External Entity Type, which provides you a great deal of flexibility in linking a Journey to many of its associated Entities. This means that you can connect a Journey to both a Customer and Contact in Chassi and also link to their corresponding customer and contact in your database, Salesforce or any other systems of record; thus creating an implicit connection that your integration can enforce.

The following table shows the exposed Entity Type's for Chassi Customers for use. When linking the Entity Type to the Journey, the Entity Type Identifier is used in the Entity Array.

Entity Type	Entity Type Identifier	Description
Customer	customerId	The Customer Entity is the most used data type for Chassi defined Entities. Using Customer means you will link the Journey to a Customer in Single Customer View.
Contact	contactId	Using Contact means you will link the Journey to a Contact in Single Customer View.

While you can include multiple Entity Types, you can only include one of each type of Entity. So this means you can link both Customer and Contact, as an example, but you cannot link two different Customers. If you need to create a manifest of a resource, like linking ten customers, consider putting them in the metadata or using an External Entity Type and creating a composite key and/or metadata.

📘

Future Data Types

In the future, we will expose additional Entity Data Types for Resources, Orders, Users and more, as we release these entities into the Chassi product line.

The following table shows External Entity Type Identifiers that are exposed to Chassi Customers for use and shows examples of how it can be extended to provide additional types. The External Entity Type Identifier is used in the External Entity Array of the Journey for connecting your External Entity.

External Entity Type Identifier	Description
customerId	Your Definitional Space is pre-seeded with this external data type. This allows you to tie your external customer id to the Journey. Usage of this External Entity Type is optional, and you could choose to use a completely different type for the same purpose if you wanted.
contactId	Your Definitional Space is pre-seeded with this external data type. This allows you to tie your external contact id to the Journey. Usage of this External Entity Type is optional, and you could choose to use a completely different type for the same purpose if you wanted.
userId	This is an example of something you can seed your Definitional Space with so you could tie your "User"'s resource id or database id to a Journey.
patientId	This is an example of something you can seed your Definitional Space with so you could tie your "Patient"'s resource id or database id to a Journey.

❗️

CustomerId is Reserved

The CustomerId is used so you have a way to refer to external customers, but it is also used by Chassi to specifically support the deprecated ExternalCustomerId property in the journey. If you are using the deprecated ExternalCustomerId, DO NOT delete the CustomerId entity data type from your External Entity Array because we map the old property to this entity type. Otherwise, if you want to link to an external customer, feel free to use this pre-populated entity type for that purpose. Pre-populated entity data types can be used, deleted, etc as you will, otherwise.

While Chassi does not provide the ability to guarantee uniqueness or the cardinality of your entity types in your journeys (i.e., making sure that only one journey exists for a specific lifecycle for a specific customer), we do provide the endpoints necessary for you to provide your implementation help in ensuring that you can perform consistency checks for cardinality purposes when you need to enforce it.

As an example, here is an illustration where we want to reference our customer as a Salesforce Account and track the users in our application database as contacts.

Example Entity usage in Chassi

As you can see from the diagram, we are using the SalesForce Account as our system of record for the "Customer" and we are using our own application's record of the User as the system of record for "Contact." This is just an example of having a system of record in two separate systems, but you could have the system of record be in a single system and reference that in the journey and optionally, in Single Customer View as well.

We are able to reference the AccountId in the Journey with an ExternalEntityType of CustomerId and also link the Customer record in Single Customer View, using the ExternalCustomerId property. Then we can have bi-directional access to both the Customer as well as the Contact.

You don't have to use Customer or Contact in Single Customer View if you don't want to. You could completely use Journeys in Lifecycle with only using the External Entity types, and even create your own to reference any system of record outside of Chassi.