Second-Generation Managed Packaging Developer Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
Second-Generation Managed Packages
What’s a Second-Generation Managed Package?
Set Up Your Development Environment
Before You Create Second-Generation Managed Packages
Scratch Orgs and Package Development
Workflow for Second-Generation Managed Packages
Components Available in Second-Generation Managed Packages
Behavior of Specific Metadata in Second-Generation Managed Packages
Develop Second-Generation Managed Packages
Install and Uninstall Second-Generation Managed Packages
Prepare to Distribute Your Second-Generation Managed Package
Push a Package Upgrade for Second-Generation Managed Packages
Advanced Features for Second-Generation Managed Packages
Best Practices for Second-Generation Managed Packages
Manage Licenses for Managed Packages
Manage Features in Second-Generation Managed Packages
Get Started with AppExchange App Analytics
App Analytics Use Cases
Enable App Analytics on Your Second-Generation Managed Package
Download Package Usage Logs, Package Usage Summaries, and Subscriber Snapshots
Considerations for Custom Interactions
AppExchange App Analytics Best Practices
Package Usage Summaries
Package Usage Logs
How to Read App Analytics Package Usage Log Data
Determine What Packaged Component Was Accessed
Identify Who Interacted with Your Packaged Component
Identify How a User Interacted with Your Packaged Component
Custom Object and External Object Interactions
Lightning Interactions
Apex Interactions
Visualforce Interactions
CRM Analytics Asset Interactions
Custom Interactions
Package Usage Logs Schema
Subscriber Snapshots
Test Custom Integrations
AppExchange App Analytics Developer Cookbook
Gaps Between First-Generation and Second-Generation Managed Packaging
PDF

Identify Who Interacted with Your Packaged Component

After you identify your packaged component, identify both the subscriber org and the user who triggered the interaction.
Available in: both Salesforce Classic and Lightning Experience
Available in: Enterprise, Performance, Unlimited, and Developer Editions

  • Identify the subscriber org with the organization_id. Some standard fields are always populated and provide you with info about the subscriber org. Some supplemental fields, when populated, add detail about that org.
    This table describes the subscriber org fields.
    Standard Fields Supplemental Fields
    • organization_name
    • organization_status
    • organization_edition
    • organization_type
    • organization_country_code
    • organization_language_locale
    • organization_time_zone
    • organization_instance
    • cloned_from_organization_id
  • Use the user_id_token to identify and describe the user associated with the interaction. This hashed token represents the ID of the user who accessed the package. The ID persists, even if a user’s details change, across any packages that the user interacts with.
    These supplemental fields, when populated, can provide you with more data about the user.
    • user_type
    • user_agent
    • user_country_code
    • user_time_zone
    • session_key
    • login_key

    Because user_id_token can represent many different usage situations, we don’t recommend using App Analytics for auditing customer license usage.