Salesforce UserInfo session type in APEX

Understanding Salesforce UserInfo Session Type in Apex

Explore the nuances of UserInfo.getSessionType() in Salesforce Apex, its common use cases, and how to accurately identify the context of a user's session.

In Salesforce Apex development, understanding the context in which your code executes is crucial for security, performance, and proper functionality. The UserInfo class provides a wealth of information about the currently logged-in user, and one particularly useful method is UserInfo.getSessionType(). This method allows developers to determine the type of session from which the current Apex transaction originated, enabling tailored logic for different user experiences, such as standard UI, API calls, or Visualforce pages.

What is UserInfo.getSessionType()?

The UserInfo.getSessionType() method returns a string representing the type of session associated with the current user's context. This string can vary depending on how the user is interacting with Salesforce. Knowing the session type helps in implementing conditional logic, such as restricting certain operations for API-only users or providing different UI experiences based on the session origin. It's a powerful tool for building robust and context-aware Apex applications.

String sessionType = UserInfo.getSessionType();
System.debug('Current Session Type: ' + sessionType);

Basic usage of UserInfo.getSessionType() in Apex.

Common Session Types and Their Meanings

Salesforce defines several session types, each indicating a different way a user or system is interacting with the platform. Here are some of the most common ones you'll encounter:

• 'STANDARD': This is the most common type, indicating a user logged in through the standard Salesforce web interface (Lightning Experience or Salesforce Classic).
• 'API': This type signifies that the current transaction originated from an API call, such as SOAP, REST, Bulk API, or Metadata API. This is crucial for distinguishing programmatic access from interactive user sessions.
• 'VISUALFORCE': When a user interacts with a Visualforce page, this session type is returned. It helps differentiate between standard UI interactions and those within a custom Visualforce context.
• 'SLDS': Indicates a session originating from a Lightning Component or Lightning Web Component (LWC) within Lightning Experience.
• 'APP': Often associated with mobile applications or other custom applications built on the Salesforce platform.
• 'REMOTE_ACCESS': Can be returned for sessions initiated via OAuth or connected apps.

Understanding these distinctions allows developers to implement fine-grained control over their application's behavior.

flowchart TD
    A[User Action] --> B{Session Type?}
    B -->|STANDARD| C[Standard UI Logic]
    B -->|API| D[API Call Logic]
    B -->|VISUALFORCE| E[Visualforce Page Logic]
    B -->|SLDS| F[Lightning Component Logic]
    B -->|Other| G[Generic/Fallback Logic]
    C --> H[Execute Apex]
    D --> H
    E --> H
    F --> H
    G --> H

Decision flow based on Salesforce session types.

Practical Use Cases for Session Type Detection

Leveraging UserInfo.getSessionType() can solve various architectural and functional challenges:

1. Security and Data Integrity: Prevent certain sensitive operations (e.g., mass data deletion) from being executed via API calls, or require additional authentication steps for non-standard sessions.
2. User Experience Customization: Display different messages, redirect users, or enable/disable UI elements based on whether they are in a standard browser session or a mobile app.
3. Logging and Auditing: Enhance logging by including the session type, providing better context for troubleshooting and security audits.
4. Preventing Recursion/Infinite Loops: In complex integrations, sometimes an API call might trigger a process that then makes another API call. Checking the session type can help break such loops.
5. Performance Optimization: For API calls, you might skip certain UI-specific validations or triggers that are unnecessary and can impact performance.

public class SessionTypeHandler {
    public static void handleRecordUpdate() {
        String sessionType = UserInfo.getSessionType();

        if (sessionType == 'API') {
            // Logic specific to API calls, e.g., skip UI-specific validations
            System.debug('Record update initiated via API. Skipping UI validations.');
            // Perform API-specific data processing
        } else if (sessionType == 'STANDARD' || sessionType == 'SLDS') {
            // Logic for standard UI or Lightning components
            System.debug('Record update initiated via UI. Applying standard business rules.');
            // Perform standard UI-driven data processing
        } else if (sessionType == 'VISUALFORCE') {
            // Logic for Visualforce pages
            System.debug('Record update initiated via Visualforce.');
        } else {
            System.debug('Record update initiated from unknown session type: ' + sessionType);
        }
        // Common logic for all session types
        System.debug('Executing common record update logic.');
    }
}

Example of conditional logic based on session type.

Considerations and Best Practices

While UserInfo.getSessionType() is a powerful tool, keep the following in mind:

• Future-Proofing: Salesforce may introduce new session types in the future. Design your code to handle unknown session types gracefully, perhaps with a default or fallback behavior.
• Testing: Thoroughly test your logic across different session types (e.g., through the UI, via Workbench for API calls, and within a Visualforce page) to ensure it behaves as expected.
• Security Context: Remember that UserInfo.getSessionType() only tells you how the user is interacting, not who the user is or their permissions. Always combine this with proper permission checks and sharing rules.
• Governor Limits: Using UserInfo.getSessionType() itself does not consume significant governor limits, but the conditional logic you implement based on it might. Be mindful of your overall transaction limits.