SAM Pro modeling guidance for Alteryx Enterprise Full Creator

[meganfisher]

I’m looking for guidance and best‑practice recommendations on how to correctly model Alteryx licensing in ServiceNow SAM Pro so that Alteryx Designer installs are properly included in reconciliation and consume against our entitlements.

Background / Context

• We are invoiced by Alteryx for “Enterprise Full Creator” licenses (named‑user).
• These licenses entitle users to:
  • Alteryx Designer (desktop and/or cloud)
  • Other platform capabilities such as App Builder, Auto Insights, Plans, Copilot, automation services, etc.
• From a discovery standpoint, the only installed/discoverable component we have is Alteryx Designer (Desktop).
• The other capabilities are cloud/platform services and do not generate install evidence.

Where we’re struggling

We’re trying to ensure that:

• Alteryx Designer installs are counted in reconciliation
• Consumption aligns to what we are actually invoiced for (Enterprise Full Creator)
• We avoid incorrectly splitting cost or creating “phantom” licensable products

Specific questions we’re hoping the community can clarify

1. Entitlements vs installs

   • We have entitlements for Enterprise Full Creator, but the only normalized installs we see are for Alteryx Designer.
   • What is the recommended pattern for ensuring Designer installs consume against Enterprise Full Creator licenses without misrepresenting the license structure?

2. Publisher / Product on the software model

   • Should the licensable software model use:
     • Publisher/Product = Alteryx / Alteryx Designer (to align with normalization), or
     • Publisher/Product aligned to the commercial packaging (Enterprise Full Creator)?
   • How are others handling this when the commercial license name does not match the installable product name?

3. Compliance calculation

   • Since App Builder, Auto Insights, Designer Cloud, etc. are not installed products and provide no discovery data:
     • Is the expected/accepted approach to calculate compliance solely based on Alteryx Designer install and/or user evidence, with other capabilities treated as implicitly covered by the same license?
     • Are there any supported patterns to represent these platform capabilities without creating separate licensable models?

4. Behavior when there are no active rights

   • We’ve observed that Alteryx Designer installs do not appear in the reconciliation/compliance calculation when there are no active entitlements (rights) associated to the software model.
   • Is this expected SAM Pro behavior (i.e., installs are excluded from compliance until rights exist)?
   • If so, what is the recommended way to identify unlicensed usage during initial onboarding when entitlements have not yet been created?

What we are trying to avoid

• Splitting Enterprise Full Creator cost across multiple pseudo‑products
• Creating separate entitlements for non‑discoverable platform services
• Breaking normalization by forcing Designer installs to match a bundle name
• Over‑engineering parent/child models where only one real install exists

If anyone has modeled Alteryx (or similar Enterprise / role‑based platform licenses) successfully in SAM Pro, we would really appreciate insight into:

• Software model structure
• Entitlement setup
• Any platform nuances we should be aware of

Thanks in advance for any guidance or examples you’re willing to share.

[Naveen20]

Try this ..

---

1. Entitlements vs. Installs — the "Suite with one discoverable product" pattern

The cleanest approach is to model Enterprise Full Creator as a suite software model with Alteryx Designer as its single child product model. In SAM Pro terms:

Create a software model record where the metric type is "User" (named-user), the model type is set to Suite, and the publisher is Alteryx. Then associate Alteryx Designer as a child product under that suite. When you create your entitlement (purchase/contract right) against the suite model, the reconciliation engine will look downward into the child products for install or usage evidence. Designer installs will roll up and consume against the Enterprise Full Creator entitlement automatically.

This avoids forcing the normalization library to map Designer installs to a bundle name it doesn't recognize, and it avoids creating phantom licensable products for cloud-only capabilities.

2. Publisher / Product on the software model

Use both — but at different levels of the hierarchy:

The suite-level model should reflect the commercial packaging: Publisher = Alteryx, Product = Enterprise Full Creator (or however the SKU reads on your invoice). This is where your entitlement lives and where cost sits. The child product model should align with what normalization produces: Publisher = Alteryx, Product = Alteryx Designer. The normalization library will map discovered installs to this child, and the suite relationship ensures consumption flows upward.

Do not try to rename or re-normalize Designer installs to "Enterprise Full Creator" — that breaks the normalization chain and causes ongoing maintenance headaches every time the norm library updates.

3. Compliance calculation for non-discoverable platform capabilities

The accepted approach is exactly what you're intuiting: calculate compliance solely based on Alteryx Designer install/user evidence, and treat the cloud capabilities (App Builder, Auto Insights, Designer Cloud, Copilot, etc.) as implicitly covered by the same named-user entitlement.

Do not create separate licensable software models for those cloud services unless you have a specific compliance or cost-allocation requirement that demands it. Here's why:

• They produce no discovery evidence, so they'll always show zero consumption and 100% compliant, which adds noise to your reporting.
• Splitting the entitlement cost across multiple child products creates an artificial allocation problem that doesn't reflect how the vendor invoices you.
• If you ever need to track usage of cloud components (e.g., for optimization — "do we actually use Auto Insights?"), that's better handled through a usage analytics or SaaS management approach outside of SAM Pro's install-based reconciliation.

If management or audit asks "what does the Enterprise Full Creator license cover?", document the full bundle contents in the Description or Notes field on the suite software model record. That gives you traceability without polluting the compliance calculation.

4. Behavior when there are no active rights

Yes, this is expected SAM Pro behavior. The reconciliation engine only includes installs in the compliance calculation when there is at least one active entitlement (right) associated to the software model. If no rights exist, those installs are effectively in a "not managed" state — they won't show as non-compliant because there's no license baseline to measure against.

To identify unlicensed usage during initial onboarding before entitlements are created, use one of these approaches:

• Software Install report or CMDB query: Query cmdb_sam_sw_install filtered to Publisher = Alteryx. This gives you raw install counts independent of whether a software model or entitlement exists. You can use this to baseline your exposure before modeling.
• Unmanaged Software view: SAM Pro has an "Unmanaged Software" or "Software without Model" view (depending on your version) that surfaces discovered products not yet associated with a licensable software model. Designer should appear here if you haven't built the model yet.
• Create the model and rights with zero quantity initially: Another pragmatic approach — stand up the suite model and a placeholder entitlement with quantity = 0. Reconciliation will then show Designer installs as over-consumed, which gives you the compliance gap visibility you need to justify procurement of the right number of licenses.

---

Putting it all together — recommended setup

The structure looks like this: one suite software model (Enterprise Full Creator, metric = User, type = Suite) with one child product model (Alteryx Designer, metric = User). Your entitlement record sits on the suite with the purchased quantity matching your invoice. Normalization maps discovered installs to the Designer child. Reconciliation rolls Designer consumption up to the suite and calculates compliance there.

For the entitlement record itself, set the license type to Named User, tie it to the suite model, enter your purchased quantity, and associate the relevant contract or PO. If your procurement records the per-user cost at the Enterprise Full Creator level, keep the full unit cost on the suite entitlement — don't try to decompose it across bundle components.

A few platform nuances worth noting:

• Make sure the "Include in reconciliation" flag is enabled on both the suite and child software model records.
• If you're on Washington DC or later, confirm that the normalization rule for Alteryx Designer is mapping to the correct product record you're using as the child. Sometimes the norm library creates its own product record and yours is a duplicate — reconcile those before building the model.
• Named-user metric reconciliation in SAM Pro can work off install evidence or user-based allocation depending on your configuration. If you want to track by assigned user rather than just install count, make sure user-device associations are populated (typically from discovery or HR feed).

[meganfisher]

Thank you for this information and it's very helpful. The product of "Enterprise Full Creator" isn't a product in the content library currently. Should we use a custom software product or should we submit a content request to have this product added to the content library?

[Naveen20]

Create a custom product record for "Enterprise Full Creator" under the Alteryx publisher. Set it as your suite-level product and build your software model against it now. This gets your reconciliation running and your compliance posture visible without delay.

When creating the custom product, a few things to keep in mind:

• Use the existing Alteryx publisher record from the content library rather than creating a duplicate publisher. This keeps your normalization and reporting consistent.
• Mark the product as "User Created" or equivalent so you can distinguish it from content-library-managed records later.
• Set the product category and lifecycle fields appropriately so it doesn't get flagged as unclassified in your reporting.
• In the description, note that this is a commercial bundle/suite SKU and list the included capabilities for documentation purposes.

Parallel step — submit a content request

It's still worth submitting a content request to ServiceNow's content library team (through the SAM Content Request module or via HI/support portal) asking them to add Enterprise Full Creator as a recognized product. Include the exact SKU name from your Alteryx invoice, the publisher, and a note that it's a named-user suite containing Alteryx Designer plus cloud platform capabilities.

The benefit of having it in the official content library is that future normalization updates won't conflict with your custom record, and if Alteryx changes their packaging or naming, the content team will track that for you. It also helps other customers who are modeling the same thing.

What to watch for when the content request is fulfilled

Once the content library adds the product (if they do), you'll want to reconcile your custom record with the new library record. Typically this means remapping your software model to point at the content-library product and retiring your custom one. Do this carefully — make sure your entitlement, suite-child relationships, and any reporting references are updated in the same change window so you don't temporarily break reconciliation.