Snap can be utilized to query, insert, update, delete, and attach files with any object in Salesforce. Salesforce Snap blocks can only be used on server-side rule such as workflows and safe functions. If you want this data to appear in a configurator, simply write your safe function then call the function from a rule in the configurator.
Querying Salesforce Objects
Querying can be done by passing SOQL into the Salesforce query block, as in the following example.
This example queries salesforce for a Epicor CPQ quote object (called "KBMAX__Quote__c") by its id. All results are returned as an array of objects, so here we return only the first object from the array.
Inserting Salesforce Objects
Inserting Salesforce objects involves setting up the object (typically a name-value pair which you can express as a map or defined type) which correspond to the object in Salesforce. All properties considered non-nillable by Salesforce must be filled in. After insertion, the result of the call will be the id of the new object that was inserted.
Example 1: Inserting a Lead using a Map
The following example illustrates a workflow action which will insert a lead (in this case manifesting as the quote owner) into Salesforce.
Example 2: Inserting a Lead using a Type
Using declared types to correspond to any Salesforce counterparts can help ensure that each invocation of the object will use the same known properties and mitigate the possibility of misspelling a property name. Here, for example, we create a type with properties like "Company" and "Description" -- the spelling must match exactly the object properties Salesforce.
The above type has a subset of the lead properties Salesforce expects. If a Salesforce property is nillable it does not need to be in this list.
Once the type is defined (usually as a global type, so it can be used anywhere), it can be used to define a variable. The variable is populated with the necessary attributes, and passed into the Salesforce Client block:
Instantiating this type ensures that the properties you are passing into Salesforce are consistent.
Example 3: Inserting one or more Attachments
Another example of inserting, this time in the snap block for a workflow stage. Here, when a build is complete, we first ensure that the quote in Epicor CPQ has the field "externalID" set. If you are using our standard salesforce integration, this field is populated for you with the ID of the matching salesforce object. If we have that externalId (and, therefore, a place to put our attachments in salesforce), then we gather all Epicor CPQ-generated outputs that have been built and tagged with "attach_to_quote" and copy them to salesforce. On those attachments in salesforce, we set the "salesforce parent object ID" with that externalID. Because we set that ID, these attachments will then appear in the salesforce quote's "Notes and Attachments" or "Files" related list.
Updating Salesforce Objects
Updating is similar to inserting, except you also pass in the id of the object to update. In this case, you only need to send the properties you intend to update, with their updated values.
Deleting Salesforce Objects
Performing Multiple Calls
Things to remember
Omitted properties are unchanged
Any properties omitted from the update will remain unchanged in Salesforce. In the above code, for example, the only property this function updates in a lead is the "Email" property. Other properties, such as "FirstName" and "LastName", remain as they were originally. If you don't want this behavior, and want other parameters to be cleared, simply set each of those other parameters to be an empty string (for text values) or the number zero (for numeric values).
Another example of updating a salesforce object, this time in a workflow rule. Note that the "salesForceClient" variable has already been declared previously in the same workflow rule, so it is being re-used here.
To delete a Salesforce object, simply pass in the id of the object you'd like to delete.
Note that the salesForceClient object that automatically gets attached to the Salesforce blocks after you pull them out of the toolbox only needs to defined once. You can make multiple Salesforce calls using the same client.
If you're writing to salesforce, remember you are working through the salesforce API. This means:
- The API names of fields are used, not the display names. Names of custom fields in salesforce will end with "__c"
- Some fields visible in the UI are not available in the API.
For example, on the Lead object you cannot write to the "Address" field. That field is computed automatically from the "Street", "City", "State", and "Postal Code" fields, and cannot be written to. If you find a situation where you are not able to write as you expect, try writing that same information directly to your Salesforce API through an API testing tool like Postman. Confirm the Salesforce API syntax first, then implement that syntax in Epicor CPQ. - Some complex salesforce types, like the phone type, are expressed through their API as the simple text type.
- Remember, your query result object gives you useful information.
For example, when performing an insert using Snap in Epicor CPQ, the result object will give you the salesforce unique ID number of the record you've just created in salesforce. - Concerned with slow performance?
Remember that any custom triggers or workflows that have been developed in Salesforce are in effect when Epicor CPQ writes to Salesforce, unless you adjust your design in Salesforce.