Native SaaS Integrations Need Configurable Consumption-to-Software Model Mapping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
8m ago
The Problem
I've encountered a licensing reconciliation issue with ServiceNow's native DocuSign Organization-level SaaS integration that highlights a broader limitation potentially affecting other native SaaS integrations.
The integration successfully retrieves envelope consumption through the API but assigns that consumption to the generic OOB software model: DocuSign DocuSign Envelopes
However, the customer's existing purchased entitlement is associated with the correctly identified PPN-based software model: DocuSign eSignature for Salesforce Enterprise Pro Envelopes
Because ServiceNow reconciles consumption against entitlements associated with the same software model, the imported envelope consumption is reported as unlicensed, even though the customer has sufficient purchased rights.
The API integration works correctly in retrieving consumption data. The issue is how that consumption is associated with the customer's existing software licensing.
ServiceNow's Current Recommended Solution
ServiceNow Support recommends creating a new software entitlement against the generic integration-generated software model while leaving the existing PPN-based entitlement unchanged.
This approach is also associated with ServiceNow's published guidance:
The existence of a dedicated KB article suggests this is a recognized scenario that may affect other customers.
Unfortunately, the recommended approach introduces significant SAM concerns:
Duplicate licensing rights: Creating another entitlement with the same purchased quantity can double-count owned licenses across software models.
Inaccurate license positions: The original PPN-based entitlement continues to appear unused while consumption is reconciled against another model.
Inflated overlicensing costs: Unused rights on the original entitlement can falsely increase the dollar value reported as overlicensed software.
Potential duplicate financial reporting: Maintaining two entitlements for the same purchase risks overstating licensing costs.
Alternatively, moving the existing entitlement to the generic model compromises the accuracy of the PPN-based software model and its commercial product identification.
Customers should not have to duplicate purchased entitlements or associate them with a different product model simply to accommodate the identifiers used by a native API integration.
Technical Findings
Investigation of the DocuSign Organization-level integration indicates that envelope consumption is assigned to a software model derived from the integration's user-subscription model attributes, including Product, Version, Edition, and Unit of Consumption.
The process does not directly use the purchased entitlement's PPN to select the consumption software model.
Although ServiceNow provides subscription identifier and custom subscription product definition capabilities, these do not necessarily control the separate envelope-consumption model resolution process.
This creates a disconnect between commercially purchased software entitlements and API-discovered SaaS consumption.
Proposed Product Enhancement: Customer-Configurable SaaS Consumption Model Mapping
ServiceNow should introduce a reusable SaaS Consumption Software Model Mapping capability for native API integrations.
Customers should be able to configure how imported consumption maps to an existing software model without changing OOB integration code or duplicating entitlement records.
Ideally, the enhancement would provide:
Integration-level configuration: Select the appropriate existing software model for a specific SaaS integration profile and consumption metric.
Customer-defined mapping precedence: Allow an active customer mapping to override the generic OOB model selection without modifying vendor-maintained definitions.
Identifier-based mapping: Support relevant subscription identifiers, product/SKU identifiers, account identifiers, or other integration attributes when available.
Separate subscription and consumption mapping: Preserve user-subscription software models while independently mapping consumption-based metrics such as envelopes, API transactions, credits, or storage.
Existing entitlement preservation: Reconcile consumption against the customer's existing PPN-based software model while retaining purchased rights, contract details, and licensing costs.
Persistent and auditable mapping: Maintain the configuration across integration refreshes and content updates, with appropriate handling of existing consumption summaries to prevent duplicate consumption.
Expected Result
For DocuSign, customers could configure the integration to associate envelope consumption with their existing PPN-based software model while continuing to use the generic DocuSign model for user subscriptions.
The existing purchased entitlement would remain unchanged, and reconciliation would accurately reflect consumption against the purchased rights.
More importantly, this capability could be applied to any native SaaS integration where API-generated consumption does not align with the software model established through PPN-based entitlement creation.
Questions for the ServiceNow Community and Product Team
Has anyone encountered similar reconciliation issues with DocuSign or other native SaaS integrations?
Is there an existing supported configuration mechanism that allows customers to override the consumption software model independently of the user-subscription model?
Could ServiceNow consider a reusable SaaS Consumption Software Model Mapping feature rather than requiring customers to create duplicate entitlements?
Accurate license reconciliation should be driven by the customer's actual purchased licensing rights—not constrained by the generic software model selected by an integration.
I'd be interested in hearing from other SAM Pro customers, implementation partners, and the ServiceNow SAM Product team about similar experiences and potential solutions.
