Find Test Classes That Cover a Specific Salesforce Apex Class

 When troubleshooting Apex code coverage, especially during deployments, it can be useful to identify which test classes currently contribute coverage to a specific Apex class or trigger.

Salesforce exposes this information through the Tooling API ApexCodeCoverage object. ApexClassOrTriggerId identifies the class or trigger being tested, while ApexTestClassId identifies the test class generating the coverage. [developer....sforce.com]

1. Get the Apex Class ID

Use the Tooling API to find the target class:

SELECT Id, Name

FROM ApexClass

WHERE Name = 'TargetApexClass'

Example:

01pXXXXXXXXXXXXXXX

2. Find Test Classes Providing Coverage

Query ApexCodeCoverage using the class ID:

SELECT

    ApexClassOrTriggerId,

    ApexTestClassId,

    NumLinesCovered,

    NumLinesUncovered

FROM ApexCodeCoverage

WHERE ApexClassOrTriggerId = '01pXXXXXXXXXXXXXXX'

NumLinesCovered and NumLinesUncovered indicate how much of the target class was exercised by the corresponding test execution. [developer....sforce.com]

3. Return Test Class Names

Instead of working with IDs, include the relationship fields:

SELECT

    ApexClassOrTriggerId,

    ApexClassOrTrigger.Name,

    ApexTestClassId,

    ApexTestClass.Name,

    TestMethodName,

    NumLinesCovered,

    NumLinesUncovered

FROM ApexCodeCoverage

WHERE ApexClassOrTriggerId = '01pXXXXXXXXXXXXXXX'

ORDER BY ApexTestClass.Name

Example output:

TargetApexClass

    TargetApexClass_Test

    ServiceHandler_Test

    BatchProcessor_Test

    IntegrationService_Test

The same test class may appear multiple times because ApexCodeCoverage can contain multiple coverage records associated with different test executions or methods. TestMethodName can be used to identify the individual method. [developer....sforce.com]

For deployment purposes, extract the unique ApexTestClass.Name values.

4. Check Overall Coverage for the Class

To check aggregate coverage instead of individual contributing tests, query ApexCodeCoverageAggregate:

SELECT

    ApexClassOrTriggerId,

    ApexClassOrTrigger.Name,

    NumLinesCovered,

    NumLinesUncovered

FROM ApexCodeCoverageAggregate

WHERE ApexClassOrTriggerId = '01pXXXXXXXXXXXXXXX'

ApexCodeCoverageAggregate represents aggregate coverage results for an Apex class or trigger. [developer....sforce.com]

Coverage percentage can be calculated as:

NumLinesCovered /

(NumLinesCovered + NumLinesUncovered) * 100

Salesforce defines Apex coverage percentage using this covered-lines-to-total-executable-lines calculation. [developer....sforce.com]

Important Distinction

Use:

ApexCodeCoverage

to answer:

Which test classes exercise this Apex class?

Use:

ApexCodeCoverageAggregate

to answer:

What is the combined coverage of this Apex class?

The ApexCodeCoverage results should be treated as current coverage relationships, not permanent code dependencies. Coverage data reflects tests that have executed and the coverage information currently stored in the org. [developer....sforce.com], [help.salesforce.com]

Deployment Use Case

When an Apex deployment fails due to insufficient coverage:

1. Identify the target Apex class ID.
2. Query ApexCodeCoverage.
3. Extract unique ApexTestClass.Name values.
4. Review or include the relevant tests in the deployment test configuration.
5. Query ApexCodeCoverageAggregate to verify the resulting class coverage.

This provides a quick way to identify existing tests that exercise a target Apex class before creating additional test classes.

Quick Guide: Components Needed for Migrating a Salesforce Experience Cloud Site

 

Display PDF Documents in a Visualforce Page from OmniScript; Secured Guest User

 

Apex: 

Overall flow:

ContentVersion File

│

▼

AutoGenDocPreviewController

│

▼

Base64 PDF String

│

▼

Visualforce Page

│

▼

JavaScript atob()

│

▼

Binary PDF

│

▼

Blob

│

▼

Temporary URL

│

▼

iframe

│

▼

PDF displayed in browser

Why This Approach Is Useful for Guest Users

Instead of exposing the file directly through:

/servlet/servlet.FileDownload?file=...

the Apex controller retrieves the file and sends it as Base64. The browser reconstructs the PDF locally.

This is often used when:

• Guest users cannot access ContentVersion directly.
• Secure Guest User Access is enabled.
• Files are owned by an integration user.
• You need custom security checks before showing the document.

Enabling users without Orchestrator access to debug on the host machine; UiPath

 

​When interactive authentication is enforced, in UiPath Assistant, a user can only see the processes to which they have access and only after signing in to their account. A user license is also required. Therefore, unattended processes which do not run under a user account are not available in UiPath Assistant for troubleshooting, making it impossible for a user to debug an unattended process by logging into that host machine.

To overcome this, an administrator can temporarily enable a troubleshooting session on their machine. Doing this lets the user see and run the unattended process locally, without requiring a user license. The troubleshooting session is temporary and the above only applies while troubleshooting is active.

You can also use Studio for its remote debugging capabilities. It allows running and debugging attended and unattended processes on remote machines, including on Linux robots that can run cross-platform projects.

Step 1. Enable a troubleshooting session​

1. Go to Tenant > Monitoring.
2. Select Unattended sessions from the Section dropdown menu.
3. Identify the machine where the error occurred, click More Actions at the end of the machine row and select Configure troubleshooting session.

The option is only available if interactive authentication is enforced.

You can find out on which machine a process ran by selecting the Processes section.

The Configure troubleshooting session dialog opens:

Figure 5. Configuring troubleshooting session

4. Under Troubleshooting session, click the toggle to switch it to Enabled.
5. In the Session timeout (minutes) box, edit the value to change the number of minutes the troubleshooting session should be active.

https://docs.uipath.com/orchestrator/automation-suite/2023.10/user-guide/configuring-automation-capabilities

Making OmniScripts Publicly Accessible: A Clear Guide

 The blog covers how to expose OmniScripts to external users via Experience Cloud (Salesforce portals/communities), but it jumps around between concepts. Here's what you actually need to do, in simple terms as mentioned in omnistudiofacts

The Three-Layer Permission Model

To make an OmniScript accessible to external users (like customers or partners using your Salesforce portal), you need to configure three permission layers.

1. Org-Wide Defaults (OWD) - Set Baseline Visibility

This controls what external users can see by default across your entire org. You need to:

• Go to Setup → Sharing Settings

• Click Edit on Organization-Wide Defaults

• Search for all Omni-related objects (OmniProcess, OmniScript, etc.) and Vlocity objects

• Set Default External Access to Public Read Only (or Public Read/Write if they need to create data)

Why this matters: Without this, external users are completely blocked from seeing OmniStudio elements, even if you grant other permissions.

2. Sharing Rules - Grant Access to Specific Records

OWD sets the baseline, but sharing rules open up access to actual OmniScript records. You need to create sharing rules for these objects:

• Omni Process

• Saved OmniScript

• Vlocity OmniScript

• Omni Data Transformation

• Omni UI Card

• Plus several DataRaptor-related objects (about 12 total)

How to set them up:

• Go to Setup → Sharing Settings

• For each object listed above, click New under its Sharing Rules section

• Choose Guest user access, based on criteria

• Set criteria: OwnerId or CreatedById Does Not Equal Null (this includes all records)

• Share with: Your Experience Cloud community name

• Access level: Read Only

Why this matters: Even if OWD allows visibility, sharing rules determine which specific OmniScript records external users can actually access.

3. Profile Permissions - Enable OmniStudio Features

The external user's profile (like "Customer Community User") needs these permissions enabled:

Critical permission:

• Under General User Permissions, enable: "Enables consumers and partners to execute OmniScripts, DRs, and Cards through a Community or off the platform"

Additional permissions to grant:

• Apex Class Access: Add all OmniStudio-related Apex classes

• Custom Metadata Type Access: Enable OmniStudio custom metadata types

• Object Permissions: Grant Read (and Edit if needed) on Omni/Vlocity standard and custom objects

Why this matters: This is the final switch that actually allows external users to execute OmniScripts - without it, nothing works even if data visibility is correct.

Below are not required but is recommended.

How to Restrict File Upload to a Single File in OmniScript (Salesforce OmniStudio)

When working with OmniScript in Salesforce OmniStudio, file uploads are a common requirement—whether it’s for document submission, verification, or case processing. However, one limitation many developers encounter is restricting users to upload only one file.

Add Formula Field to count the number of Files Uploaded.

Set Messaging element to check the value and restrict the next step. 

https://youtu.be/U5EuCACXpjA?si=_OiiAuqThL9N_QA7

DebugJSON Custom LWC to check Omniscript DebugJSON/DataJSON on Step function; Omnistudio