Salesforce Apex triggers for your Salesforce service integration indicate the conditions that will trigger your Salesforce dynamic share. Update the Apex triggers for your Salesforce dynamic shares to filter out data that is sent from Salesforce to another app. The conditions for the SOQL query that runs as part of a dynamic share's Apex trigger can be manually configured on the Apex Triggers page. To modify the default Apex triggers created for your Salesforce service integration, you will need to create a Base64 encoded condition and specify the fields you want to include in the dynamic share's outbound messages. 

First, make sure you have successfully installed DataSync. Also, for your Salesforce dynamic shares, make sure that the Active, Create, Update, and Include Attachment boxes are checked.

WARNING! If you plan to make additional changes to your Apex triggers after manually modifying them, follow the procedure via SOQL query (rather than modifying your Apex triggers in the dynamic share form) to ensure that the manual modifications to your triggers are not overridden.

Before deploying Apex triggers from sandbox to production, each trigger will require a test class to cover at least 75% of the trigger code.

A test class will need to be written to test object for the trigger code as follows:

• Trigger Actions - If the dynamic share has insert, update and/or delete selected. The test class will need to do the respective action selected (i.e. insert the object).
• Trigger Conditions - An object matching the dynamic share conditions will need to have matching action(s) (such as an insert).
• Apex Object Requirements - Mandatory fields required to do the action(s) above. For example, if the dynamic share is on the Contract object which requires the AccountId field be populated in order to insert a new Contract object. The AccountId field is a reference field to the Account object and requires an Account be created first.
• Extra Trigger Options - Any other additional related triggers (such as Attachment and ContentDocumentLink triggers created when selecting the Include Attachments option) created with the dynamic share to share out those related records that will also need to be tested for trigger code coverage.

See below test class for an example of testing a dynamic share Apex trigger created on the Contract object:

• Trigger Actions - The insert and update actions are selected on the dynamic share so the test class inserts and updates Contract objects.
• Trigger Conditions - The dynamic share is set to only trigger and executed when the Contract object's Status != 'Draft'. Contract objects are inserted with the Status = 'Draft' and then updated to 'In Progress'.
• Apex Object Requirements - The Contract object requires the AccountId, Contract__Type__c, StartDate, EndDate, Preferred_Complement_Date__c fields to be populated. These fields are populated when created test Contract objects. Since AccountId is a reference field to the Account object, test Account objects are created first to use for this field.
• Extra Trigger Options - The dynamic share has the Include Attachments option selected to trigger and share out attachments when they are added. Test Attachment and ContractDocumentLink objects are created to test these triggers and share out those objects. 

@isTest(SeeAllData=true)
global class PSPContractTriggerTest {
    private static testmethod void  TestPSPContractTrigger() {
        List<persp__psp_replicate_conf__c> shares = [select Id,persp__create__c,persp__update__c,persp__delete__c,persp__table__c from persp__psp_replicate_conf__c where persp__table__c='Contract'];
        System.debug('Found Share: ' + shares.size());
        for(persp__psp_replicate_conf__c share : shares){
            System.debug('processing table: ' + share.persp__table__c);
            SObject shareObj = Schema.getGlobalDescribe().get(share.persp__table__c).newSObject() ;

			//Account object is required to create a Contract
            Account testAccount = new Account(name='PSP_Test Account');
            insert testAccount;
            String testName = 'PSP_Test';
            List<Contract> contractList = new List<Contract>();
            for(Integer i = 0; i <= 200; i++){  
                Contract testContract = new Contract(  
                    AccountId = testAccount.id,
                    Name = testName + i,
                    Short_Description__c = testName,
                    StartDate = System.today() + 1,
                    EndDate = System.today() + 3,
                    Preferred_Completion_Date__c = System.today() + 2,
                    Status = 'Draft',
                    Contract_Type__c = 'Other'
                );
                    
                contractList.add(testContract);
            }
                
            insert contractList;
                
            if(share.persp__update__c){
                String q = 'select Id, Status from ' + share.persp__table__c + '  WHERE Short_Description__c =: testName LIMIT 1';
                List<Contract> sobjList = Database.query(q);
                if (sobjList.size() == 0)
                    continue;
                 
                System.debug('returned: ' + sobjList.size());
                System.assertEquals(sobjList.size(), 1);
                for(Contract o : sobjList){
                    o.Status = 'In Progress';
                    update o;
                    
              		
                    String body1='x';
                    Blob b = Blob.valueOf(body1);
                    Attachment attach1= new Attachment();
                    attach1.Name = 'Test Attachment';
                    attach1.ParentId = o.Id;
                    attach1.Body = b;
                    insert attach1; 
            
                    attach1.Name = 'Updates Test Attachment';
                    update attach1;
                    System.assertEquals(attach1.Name, 'Updates Test Attachment');
                    delete attach1;
                    
                    
                 
                    //ContentDocumentLink Test                    
                    ContentVersion contentVersion = new ContentVersion(
                      Title = 'Test',
                      PathOnClient = 'Test',
                      VersionData = Blob.valueOf('Test Content'),
                      IsMajorVersion = true
                    );
                    insert contentVersion;    
                    List<ContentDocument> documents = [SELECT Id, Title, LatestPublishedVersionId FROM ContentDocument];
                    
                    //create ContentDocumentLink  record 
                    ContentDocumentLink cdl = New ContentDocumentLink();
                    cdl.LinkedEntityId = o.id;
                    cdl.ContentDocumentId = documents[0].Id;
                    cdl.shareType = 'V';
                    insert cdl;
                    cdl.shareType = 'I';
                    update cdl;

					try {
 						Delete cdl;
					} catch (Exception e) {
    					System.debug('Error deleting ContentDocumentLink');
					}

                } // end for(Contract o : sobjList){
            } // end if(share.persp__update__c){
        } // end for(persp__psp_replicate_conf__c share : shares)
     } // end testmethod()
}  

Receipts are automatically generated in your Salesforce org for your integration. Receipts indicate the delivery status for records that have been shared from your ServiceNow instance to your Salesforce org, allowing you to quickly identify successfully synced records as well as any records that have not yet been synced. Receipt delivery statuses include:

• Success Your records were synced successfully

• Pending Your Salesforce org is still processing the records shared out from your ServiceNow instance

• Error Your records were not synced successfully

To view the receipts generated in your Salesforce org for data being shared out by ServiceNow, follow these steps:

1. Log into your Salesforce organization and click the  icon in the upper left-hand corner of the screen. Then, click the Perspectium Replicator app.
   
   

2. In the navigation bar near the top of the screen, click Receipts. Then, on the resulting page, click into the receipt that you want to view. Note that the receipt's delivery status will be listed as the value in the Batch Type field for the receipt.

    NOTE: Keep in mind that receipts generated within Salesforce are receipts for data coming into Salesforce (inbound data). To view information for receipts for data coming out of ServiceNow (outbound data), see ServiceNow messages & receipts.

By default, Salesforce receipts will be generated for every 1,000 ServiceNow messages. However, you can change this default value within the Replicator Settings for your Salesforce org.

1. Log into your sandbox Salesforce organization and click the  icon in the top right-hand corner of the screen. Then, click Setup.
   
   
2. In the Quick Find window on the left side of the screen, type and then click Custom Settings (under Custom Code).
   
   
3. Locate the ReplicatorSettings label from the list of Custom Settings. Then, under the Action column, click Manage for ReplicatorSettings.
   
   
4. On the resulting ReplicatorSettings page, click Edit. Then, modify the values for the Batch Ack Size and Batch Error Size fields to be the number of messages (as a batch) that will trigger the generation of a receipt within Salesforce for inbound data.
   
   
5. Click Save.

The Include Child Records option provides a way to share out child records of a parent record. This is done by creating Apex triggers so as to capture events on those child tables, and filtering to only share out child records related to the parent record.

After selecting the parent table on a dynamic share form, the Include Child Records option will populate with child tables that support Apex triggers. Select those tables where you want to share child records from.

For example, if you select the Case table for the dynamic share and want to share out comments on Case records, select the CaseComment table in the Include Child Records option:

Like attachments, this option currently only supports sharing out all fields of the child tables.

As is the case with the Apex trigger created for the parent table specified in the share, any triggers created for the child tables will be set to blank when the dynamic share is set as inactive and/or you remove a child table from the selected list (i.e. if you first select the CaseComment table in the Include Child Records option, and create a trigger for it, and then later you decide to remove the CaseComment table from the selected list). This is done to be consistent with the approach of not deleting Apex Triggers, since Apex triggers can only be created in sub-prod orgs and moved over to prod orgs. (i.e. once you delete an Apex trigger in production you can't recreate it without going through the process of doing it in a sub-prod).

Apex triggers on the child tables can be deleted but when the Apex trigger is deleted on the parent table, notably when the dynamic share itself is deleted.

You can use this feature to schedule one or more bulk shares to occur at specific times or In a repeated time interval.

1. Log into your Salesforce organization and click the  icon in the upper left-hand corner of the screen. Then, click the Perspectium Replicator app.
   
   
2. In the navigation bar near the top of the screen, click Scheduled Bulk Shares. In the upper left-hand corner of the resulting page, click New Scheduled Bulk Share.
   
   
3. Select a date and time in the Scheduled Date Time field for when to start bulk sharing records, and the Days and Hours to repeat the process in the Repeat Interval field. 
   
   
4. In the Available Bulk Shares, select which bulk shares you want to schedule and click . Check the Active box to activate the scheduled bulk share. 
   
   
5. Click Save.

Before executing a Salesforce bulk share, you can preview the bulk share to see how many records will be shared out.

1. Log into your Salesforce organization and click the icon in the upper left-hand corner of the screen. Then, click the Perspectium Replicator app.
   
   
2. In the navigation bar near the top of the screen, click Bulk Shares. In the upper left-hand corner of the resulting page, click to the bulk share you want to preview.
   
   
3. Click Preview.

After executing a Salesforce bulk share, you can clone the bulk share with the following steps: 

1. Log into your Salesforce organization and click the icon in the upper left-hand corner of the screen. Then, click the Perspectium Replicator app.
   
   
2. In the navigation bar near the top of the screen, click Bulk Shares. In the upper left-hand corner of the resulting page, click to the bulk share you want to clone.
   
   
3. Click Clone.

Salesforce sandboxes are used to develop and test changes for your organization in an environment that doesn't affect any real data or applications. When development and testing is done, you can migrate these changes from the sandbox to the production org using change sets.

This is especially useful for deploying Apex triggers in production orgs. Dynamic shares in the Perspectium Salesforce Package use Apex triggers, similar to how business rules capture changes in ServiceNow. However, unlike ServiceNow where you can create business rules in a production ServiceNow instance, Salesforce requires you deploy Apex triggers by creating them in a sandbox org and then moving them over to your production org using change sets. 

Apex triggers use Apex code to execute the Perspectium application's code to share records out of Salesforce. To deploy anything containing Apex code (such as Apex triggers) in production, you must have 75% test coverage of all Apex code. By default, the Perspectium Package comes with a test class that covers the basic components of Perspectium's Apex code including the dynamic share Apex triggers. However you may need to add an additional test class to your change set that tests your trigger's Apex code (especially if there are any customizations) to ensure this 75% coverage of all Apex code. An example of a test class that tests the dynamic share Apex trigger code can be found here.

 NOTE: Your Apex trigger trigger should reference a queue that has an alias. When migrating your Apex trigger from sandbox to production using change sets, the Apex trigger code cannot be changed. So using the same alias name when creating a queue in sandbox and creating a queue in production allows you to specify different queues in your sandbox and production orgs that can use the same Apex trigger.

Prerequisites:

 You will need to have two Salesforce orgs:

• A sandbox org sending an outbound change set
• A production org receiving an inbound change set 
• The Perspectium Package is installed and configured in both orgs before the migration process begins

Procedure:

Now that you've created a change set from your sandbox org and have sent it outbound to your production org, you can go to your production org to receive the change set inbound and deploy your dynamic share Apex triggers in production. See the next section for how to receive this change set.

To read Salesforce attachments into ServiceNow, the u_sfdc_attachment_import import set table is provided as part of the Perspectium Salesforce Update Set for ServiceNow.

The update set comes with a subscribe configuration for u_sfdc_attachment_import so records can be read into the import set table. A script action will then run on records being inserted to properly add and delete attachments.

The Perspectium message that is shared out of Salesforce for an attachment will come with a ParentTable field that has the name of the Salesforce table that you can then use to determine which table this should map to in ServiceNow.

The Set parent table to attach to business rule on the u_sfdc_attachment_import table is provided so you can modify the corresponding field in the import set table (u_parenttable) to the appropriate ServiceNow table based on how you are subscribing Salesforce records into ServiceNow.

For example, if you are subscribing Salesforce Case records into ServiceNow Incident records, you can use the following business rule to update the field:

if (current.u_parenttable == 'Case')
    current.u_parenttable = 'Incident';

Table maps

The SFDC Attachment table is included by default, therefore the table should already be set. Below is what it should look like:

Source scripts

Below are the source script for required fields above.

attributes:

answer= {"type":"Attachment"};

To configure table map to receive File sObjects from ServiceNow, add the following instead:

answer= {"type":"File"}; 

body:

var sysEncodedAttachment = new GlideSysAttachment();  
var binData = sysEncodedAttachment.getBytes(current);  
var StringUtil = (typeof GlideStringUtil != 'undefined') ? new GlideStringUtil() : new Packages.com.glide.util.StringUtil();
answer = StringUtil.base64Encode(binData);

@ExternalIdValue:

var gr = new GlideRecord(current.table_name);
gr.addQuery("sys_id", current.table_sys_id);
gr.query();
if (gr.next()){
	answer = String(gr.number);
}

table_sys_id to ParentId:

var gr = new GlideRecord(current.table_name);
gr.addQuery("sys_id", current.table_sys_id);
gr.query();
if (gr.next()){
	answer = String(gr.correlation_id);
}

Dynamic share

After configuring the dynamic share from the ServiceNow and Salesforce Configuration page, the related list is necessary when sharing attachments. It may be added in the same dynamic share. Follow the images below to properly configure the related list for sharing attachments if it is not shown on the form.

After configuring the PSP Share Table Map table to be visible on dynamic share, proceed to the bottom and select the respective tab. Click New and add the following table and table map as shown below.

By default, records subscribed into Salesforce will coalesce on the ID field to determine if we should insert a new record or update a current record. So in most cases, you will want to create JSON messages to be consumed into Salesforce with the record's ID as found in Salesforce.

For example, if you are replicating records between ServiceNow and Salesforce, you can use the table map feature of the Perspectium application to map out a field that holds the record's Salesforce Id. This Id field will generally be saved as the correlation_id field in ServiceNow tables. That way when the record is subscribed into Salesforce, it can use this Id field to find the record and update or insert as appropriate.

However there may be cases where you want records in Salesforce to coalesce on an External ID field (such as when you want Salesforce to coalesce on the replicated record's ServiceNow sys_id) since records may generally be created on another platform like ServiceNow versus starting in Salesforce. Another reason is you may prefer to have more control in the ServiceNow app and have it be your central location for all data transformation and thus want to control coalescing there as well.

Here's how:

1. Create a new custom field in Salesforce on the table where you want to coalesce on an External ID field. Make sure to select the Text field option and check the box next to External ID labelled Set this field as the unique record identified from an external system.
   
   
2. In the Perspectium application, navigate to your outbound messages to salesforce. Add ExternalIDField and ExternalIDValue attributes, so that when the message is received in Salesforce, it knows what the name of the external ID field is and what value to query for.
   

   
   

   Attribute Name	Description
   ExternalIDField	The name of the External ID field in Salesforce as created in step 1
   ExternalIDValue	A record's external ID value that we will use to query for in Salesforce in the External ID field

3. Create a field map in ServiceNow to target each of the above attributes, since it supports creating attributes in the outbound message.

Here's an example to Illustrate:

Using the above example, when the message is subscribed into Salesforce, the app will query the Case table and look for a record with ExternalID__c = 'f4e2e6104f120300b6a444b18110c726' and if it finds a record as such, use that record to update.

Here's how the table field map would look for the ExternalIDField attribute:

In this example, the ExternalIdField is scripted to always use the same value since the custom External ID field in Salesforce will always be the same field name while the record's sys_id is used for the External ID field's value.

You can schedule the MultiOutput Processing (share) and Replicator Subscriber (subscribe) jobs to run at predefined intervals, so that Salesforce data is effectively shared out. When you create a new Perspectium job for Salesforce (or edit an existing one), you can choose from a defined set of Job Intervals - the default settings include 30 seconds, 1 minute, 5 minutes, 15 minutes, 30 minutes, and 60 minutes. You may want to set your intervals to a custom time duration that isn't included in the default settings. Here's how:

1. In your Salesforce organization, go to Settings (cog icon) > Setup
   
   
2. Using the Quick Find window at the left, type and select Custom Settings (under Custom Code).
   
   
3. From the list of Custom Settings, click the one labelled ReplicatorJobSettings.
   
   
4. Under Custom Setting Definition Detail, click Manage.
   
   
5. Click New (located towards the bottom of the page)
   
   
6. Complete the fields on the Replicator JobSettings Edit form:
   
   
   • Use the Share job and Subscribe job fields to enter your desired interval(s), in seconds. For example, if you want to add an interval of 20 minutes, you would type 1,200.
   • (Optional) You can also modify the value for Max Apex Jobs.
   • Select and type a location/user.
     
     
7. Click Save.

Salesforce stores comments in a separate table, so when you share out a Case's comments, you would share out the CaseComment table and then subscribe these records into an import set table that targets the sys_journal_field table.

However, to get these comments to refresh properly in the incident's activity log as well as fire notifications, the best way to save these comments is using an onBefore transform map script in the import set table you create that targets the sys_journal_field table. Doing this will ensure that the activity log refreshes properly and any notifications set for incident comments also fire as expected. 

Based on a) the incoming CaseComment JSON containing a reference to the Case record as stored in the ParentId field (which is mapped to u_parentid when read into the import set table) and b) this Case record ID stored in the correlation_id field in the incident table in ServiceNow, this script will find the incident record to add the comment through the incident:

var incsysid='';
var inc = new GlideRecord('incident');
inc.addQuery('correlation_id',source.u_parentid);
inc.query();
if (inc.next()){
    incsysid = inc.sys_id;  //find sysid of incident from parentid in JSON
}

var gr = new GlideRecord('sys_journal_field');
gr.addQuery('name', 'incident');
gr.addQuery('element_id', incsysid);
gr.addQuery('value', source.u_commentbody);
gr.query();
if (gr.getRowCount() > 0) {
    ignore = true; // found comment already previously don't need to re-add
}
else {
    var igr = new GlideRecord('incident');
    if (igr.get(incsysid)) {
        igr.comments.setJournalEntry(source.u_commentbody);
        igr.update();
        ignore = true;
    }
}

Within the Perspectium application in your Salesforce instance, the top navigation menu includes tabs for Inbound Messages and Outbound Messages. 

The Outbound Messages tab contains records that are queued to be sent to the Perspectium server. On this tab, you can view all messages, edit or delete an existing message, and create a new message.

 NOTE: If the Status is at "Ready", the Time Processed field will be blank. Once the status is "Sent", you will be able to see how long it took for the outbound message to be sent.  

The Inbound Messages tab contains records that were shared to this Salesforce instance by other sources, such as ServiceNow. The data flowing into this table will insert or update their respective tables and record once they are processed. On this tab, you can view all messages, edit or delete an existing message, and create a new message.

Table maps

Sending to the CaseComment table is also supported. Unlike Incident to Case, the target for this table is CaseComment and the source table is Journal Entry [sys_journal_field]. Below are attached images for examples:

Source scripts

Below are the source scrips for required fields above:

attributes:

answer = {"type":"CaseComment"};

isPublished:

if (current.element.contains("comment"))
	answer = "true";

ParentId:

var gr = new GlideRecord('incident');
gr.addQuery("sys_id", current.element_id.toString());
gr.query();
if (gr.next())
	answer = gr.correlation_id.toString();

@RecordId:

var gr = new GlideRecord('incident');
gr.get(current.element_id.toString());
answer = gr.sys_id.toString();

CommentBody:

var pspUtil = new PerspectiumUtil();
var gr = new GlideRecord('incident');
gr.addQuery("sys_id", current.element_id.toString());
gr.query();
gr.next();

var elementId = gr.sys_id;
var tgr = new GlideRecord("sys_journal_field");
tgr.addQuery("element_id", elementId);
tgr.orderByDesc("sys_created_on");
tgr.query();
if (tgr.next())
	pspUtil.addTag(tgr, "msp_client_incident_sent");

answer = current.value;

Transform maps

Receiving into the CaseComment table is also supported. The source for this table is CaseComment and the target table is Journal Entry [sys_journal_field]. Below are attached images for examples:

Source scripts:

Below are the source scripts for the required fields above:

element_id:

var gr = new GlideRecord("incident");
gr.addQuery("correlation_id", source.u_parentid);
gr.query();
gr.next();
return gr.sys_id; // return the value to be put into the target field

element:

return "comments"; // return the value to be put into the target field

name:

return "incident"; // return the value to be put into the target field

Once the field mappings are created, an onBefore transform script is necessary for insertion. Refer to the image and script below for an example.

var gr = new GlideRecord("incident");
gr.addQuery("correlation_id",source.u_parentid);
gr.query();
gr.next();

var elementId = gr.sys_id;
var tgr = new GlideRecord("sys_journal_field");
tgr.addQuery("element_id", elementId);
tgr.addQuery("value", source.u_commentbody);
tgr.orderByDesc("sys_created_on");
tgr.query();
if (tgr.next() && pspUtil.recordHasTag(tgr, "msp_client_incident_sent")) {
	ignore = true;
	return;
}

pspUtil.addTag(tgr, "msp_client_incident_sent");

gr.comments.setJournalEntry(source.u_commentbody);
gr.setForceUpdate(true);
gr.update();

Dynamic share

After setting the table maps, dynamic share will be able to reference them properly. The following images are an example for configuring the ServiceNow Journal Entry (sys_journal_field) table to share out to Salesforce CaseComment object. Here is also a guide for how to set up a dynamic share.

Be sure to include the “before share script” provided below. This will defer comments that do not have a correlation id and will put it on stand by.

var gr = new GlideRecord("incident");
gr.addQuery("sys_id", current.element_id);
gr.query();
gr.next();

if ((psp_action == 'update' || psp_action == 'insert') && gr.correlation_id == ''){
	psp_action = 'deferred';
}