If you have done some automated testing, processes, or triggers in Salesforce, errors may occur when you use Salesforce Integration. This article helps you solve these common errors.
Apex Testing issue
Scenario
When performing automated testing for the organization, if the test includes a Cooby HTTP callout, an error may occur.
Solution
There are 2 methods to resolve these errors.
TestContext Class: Pretend the callout is successful to solve the error occurrence.
The TestContext class contains methods for setting up HTTP callout mocks during test execution.
setPackageMock()Purpose: Sets up a default package mock for HTTP callouts when running tests.
Usage: This method should be called to ensure HTTP callouts are mocked during test execution.
setMock(HttpCalloutMock mockInstance)Purpose: Sets up a specific mock instance for HTTP callouts when running tests.
Parameters:
mockInstance: The instance ofHttpCalloutMockto be used during tests.
Usage: Use this method to specify a custom mock for HTTP callouts during tests.
TriggerControl Class: Turn off the trigger and directly prevent the callout behavior from happening.
The TriggerControl class contains methods for managing the state of triggers (enabling or disabling them) for different sObjects.
disable(String sObjectName)Purpose: Disables the trigger for the specified sObject.
Parameters:
sObjectName: The name of the sObject for which the trigger should be disabled.
Usage: Call this method to prevent a trigger from executing for a specific sObject.
enable(String sObjectName)Purpose: Enables the trigger for the specified sObject.
Parameters:
sObjectName: The name of the sObject for which the trigger should be enabled.
Usage: Call this method to allow a trigger to execute for a specific sObject.
isDisabled(String sObjectName)Purpose: Checks if the trigger for the specified sObject is disabled.
Parameters:
sObjectName: The name of the sObject to check.
Returns: True if the trigger is disabled, False otherwise.
Usage: Use this method to verify the trigger status for a specific sObject.
disableAll()Purpose: Disables all triggers.
Usage: Call this method to prevent all triggers from executing.
enableAll()Purpose: Enables all triggers.
Usage: Call this method to allow all triggers to execute.
Post install issue
Understanding the Post Install Script
The Post Install Script runs as a special system user that represents our package. This means that all operations performed by the script appear to be done by our package.
The execution of the Post Install Script is initiated by a System API call, which imposes certain limitations on the available Salesforce features during this transaction. Some of these limitations include:
Accessing certain standard objects such as Group, CollaborationGroup, and NetworkMember, etc
Limited use of Platform Events.
DML Operations on Setup Objects. API transactions cannot perform DML operations on setup and metadata objects, such as creating or modifying user roles, profiles, or custom settings.
Triggers and Workflow Rules. Some triggers and workflow rules may not be invoked during API transactions, depending on how the transaction is structured and whether it respects the order of execution.
Session Management. API-initiated transactions do not maintain a user session in the same way as interactive sessions. This can affect session-based operations, such as maintaining state across multiple transactions.
If any of the automations in your Organization that triggers on Contact, Lead, or Cooby’s objects interact with the features above, data update might fail and you will receive an email with error messages.
Special Context and Challenges
It is important to note that the Post Install Script runs in the context of a special "ghost" user. This unique context can lead to several challenges:
Feature Restrictions: Due to the system-level execution, some Salesforce features are restricted, which may not be the case when the jobs are run manually by a regular user.
Contextual Differences: The code that runs perfectly in a regular user context may fail during the Post Install execution because of these restrictions.
Debugging Difficulties: These failures can be difficult to detect prior to release and even harder to debug when they occur. Unfortunately, there is no way to run your InstallHandler code in this "ghost" user context.
Scenario
Cooby will change Contact/Lead extensively during post-install (in order to allow our functions to run correctly). If the user has set triggers for when Contact/Lead changes, an error will occur at this time.
Solution
If you notice errors during the Post Install execution, please:
[Required] Check Error Messages: Review the error messages provided to identify the specific issues.
[Required] Review Debug Logs: Analyze the error lines to determine the cause of the errors.
[Option 1] Manually run batch for Cooby Data Maintenance: guide
[Option 2] Update or Disable Automation: Temporarily disable or update the triggering conditions of the automation processes that might be causing these errors.
We recommend checking and temporarily adjusting your org's automation processes if errors occur. This may involve reviewing and potentially updating any custom automation, triggers, or workflows that could conflict with the operations performed by the Post Install Script.
Manually run batch for Cooby Data Maintenance
Scenario
Because there is a post-install error, Cooby will not execute correctly, and the user does not want to disable these triggers.
Operation Step
Open Developer Console:
Log in to your Salesforce org.
Click on the
gear iconin the top-right corner.Select
Developer Consolefrom the dropdown menu.
Execute the Maintenance Jobs:
In the Developer Console, click on
Debugin the menu bar.Select
Open Execute Anonymous Window(or pressCtrl + E).
In the anonymous window, enter the following command:
cooby.DataMaintenanceManager.run();Click
Executeto start the batch job.
Once done, it means you have completed the manual batch job.
Verifying Batch Job Status
Navigate to Apex Jobs:
Go to Setup by clicking the
gear iconin the top-right corner and selectingSetup.In the Quick Find box, type
Apex Jobsand select it from the results.
Monitor Job Status:
On the Apex Jobs page, you will see a list of all Apex jobs.
The
Statuscolumn will show the current status of your batch job (e.g., Queued, InProgress, Completed, or Failed).We are particularly interested in five specific Apex Classes. Some of these classes might have
Total Batches: 0, indicating that there is nothing to change and you're all set.
Handling Completion and Errors
Receive Email Notification:
Once all batch jobs have completed, you may receive an email notification.
This email will contain details about any errors that occurred during the execution of the batch jobs.
If you notice any failures during the batch job runs, please be informed that these errors are directly related to the automation processes configured within your Salesforce org. To address these errors, you can follow the steps below:
Check Error Messages:
Review the error messages provided in the email notification or on the Apex Jobs page. These messages often contain details about the specific automation processes or conditions that caused the error.
Review Debug Logs:
Navigate to Setup and search for "Debug Logs" in the Quick Find box.
Review the logs to identify the exact process and conditions that triggered the errors.
Update or Disable Automation:
Once you have identified the relevant automation process, you can either temporarily disable it or update its triggering conditions to prevent the errors from occurring again.
We hope this document helps you better understand how Cooby works. For any concerns or questions regarding your Salesforce integration, kindly email us at [email protected] 💜