In previous posts about Salesforce Service Process Studio, I’ve explored strategies for building unified, reusable connectors for Service Process Studio projects. A reusable approach can be a gamechanger, making it easier to create low-code solutions, reduce maintenance headaches, and minimize downtime. And in production environments, when a customer-facing application needs to have a 99% uptime, those benefits really count.

One approach, in a previous walkthrough, I demonstrated a simple yet flexible approach to building an API connector to integrate a customer facing process with a Service Process Studio definition. This connector could pass data to the Service Process API call and kick off Service Catalog Request and Case creation. The goal was to create a universal method, one that avoids the need for a specialized Apex to map each individual use case or instance manually. Instead, we iterated through data from both Flow and OmniStudio, passing it over as strings to keep things streamlined, each value broken into a key:value pair to iterate over.

But here’s where things can get interesting, and tricky. Salesforce’s handling of field data types can be challenging. Let’s say you’re mapping data to the Case object as part of a Service Process API request. If one of the fields, like Date_of_Service__c, is a non-text type (like Date), you might run into issues. Simply passing a string value to that field through the API may not work without some additional handling. And if you’re using a minimalist approach, where you directly pass CaseAttributes as key-value pairs to the Case API fields, those data type mismatches can cause errors.

A potential workaround for this is to only send over ‘safe’ Case fields directly to a connector scenario that iterates Case destination data, and to handle Type fields on Case by adding Base Attributes in Service Process definition with their own respective field mapping and API names.

In this example, a Case field (Date_of_Service__c) is of Date type. If an Apex based controller that simply iterates over API and key:value pairs sent to it by a process were to attempt to send string values to the Date type field in the Service Process API call, an error may be encountered.

This could be handled in various ways of course, but in our goal to create a simple, universal method from a low maintenance perspective, we have a few options to keep with simple practice.

Here, an attribute mapping has been added to the Service Process definition, with its own API reference name, DateOfService. It is mapped to Case object as a Base attribute, and identified as data type Date. If in our original Omnistudio or Flow process we’ve created a key:value pair of data to send, we can reference this API field destination rather than the original ‘Date_of_Service__c’ field:

This type-mapping feature gives the Service Process definition even more flexibility and workarounds in use, towards the goal of creating simpler integrations, and reducing Apex overhead by leveraging built in features of Service Process Studio. Again, there are many ways to do things in Salesforce, but if this approach suits your development, it doesn’t have to be a showstopper when encountering special data type issues!