We're reclaiming inactive PDIs to keep them available for active builders. Learn what's changing, who's affected, and how to protect your work. Read More

Regarding Detailed Breakdown of IntegrationHub License Transaction Consumption

amiyamohant
Tera Contributor

16 hours ago

We have integrated Microsoft Teams with ServiceNow. The integration was initially deployed to Production before we had an IntegrationHub subscription. After purchasing the IntegrationHub Starter subscription, we observed that the following Microsoft Teams actions are consuming the highest number of IntegrationHub Starter license transactions, with approximately 3,500–3,800 transactions per month for each action:

  • Remove A Member from MS Teams Chat

  • Get User Presence

  • Get Chat Messages

  • List Members of MS Teams Chat

However, when we attempt to drill down into these transaction counts to understand how they are being generated from IH Usage dashboard and other sources we are unable to find any corresponding information in Flow Executions. Additionally, the Flow Designer execution logs are empty in the Production environment.

Could you please advise:

  1. Where can we view the detailed breakdown of how the IntegrationHub Starter license transactions are calculated for each of these actions?

  2. Is there any report, logging mechanism, or audit table that provides day-wise transaction details for these actions?

  3. How can we identify the specific flows, Business Rules, Script Includes, APIs, or other execution paths that are invoking these actions and contributing to the reported license consumption?

This information is essential for us to validate the reported license usage and determine the exact source of the transaction consumption.

  • 81 Views
1 REPLY 1

Vikram Reddy
Tera Guru

8 hours ago

Hi @amiyamohant,

 

This is a fairly common gap once teams actually start paying attention to IntegrationHub consumption: the platform counts a transaction the instant a spoke action's outbound call fires, but that counting event and the Flow Designer execution record are two separate things, and the second one can easily go missing even though the first one happened correctly.

For the breakdown itself, don't rely on Flow Executions for this. Go to IntegrationHub > Dashboard (the built-in Usage Dashboard, also shippable as the free Integration Hub Usage Dashboards store app if your instance doesn't already have it). It gives you transaction counts broken out by Spoke, by individual Action, and by Requestor / Caller Scope, with monthly pool consumption and day-level granularity on the egress side. That Caller Scope column is your first real lead: it tells you whether these four Teams actions are firing from a scope you own (your custom flows) or from the vendor-owned scope that ships with the Microsoft Teams / Virtual Agent integration itself. Worth checking that carefully, because presence lookups, chat membership checks, and chat cleanup are exactly the kind of thing the out-of-box Virtual Agent Teams integration runs on its own as part of presence sync, live-agent handoff, and conversation provisioning, not necessarily something a flow you built is calling.

As for why Flow Designer execution logs are empty: check Flow Administration > Properties > Flow Engine Reporting, which controls the property com.snc.process_flow.reporting.level. If that's set to Off, or even Basic, you won't get persisted step-level detail for action executions, so the Teams action calls that consumed license transactions simply won't show up as inspectable executions, even though they ran and were counted. There's also a known Now Support issue (KB3024064) where this property can silently fall back to Basic on Production instances even after you've configured a fuller logging level, which is worth ruling out given you're only seeing the gap in Production and not lower environments. Bump it to "Flows, Actions and Steps" (or Developer Trace if you need input/output payloads) temporarily so next month's activity actually gets captured, then dial it back down since full logging adds overhead you don't want running indefinitely in Prod.

One more thing to check regardless of the property: flow execution data lives in sys_flow_context, and that table gets purged by the table cleaner on a rolling basis, commonly around 30 days by default. So even if reporting was fully on, executions from further back than that window are already gone, they're not "hidden," they've aged out. If you want to trace the current 3,500-3,800/month pattern, don't chase history, turn logging up now and let a fresh cycle populate before you go looking again.

Once logging is capturing detail, search Flow Designer for every flow/subflow that references those four actions (search by action name from the flow list), and separately check any Scheduled Jobs or Script Includes that might invoke a subflow programmatically via the Flow API, since that path counts as a transaction too but is easy to miss if you're only scanning flows in the designer.

References

 

Thank you,
Vikram Karety
Octigo Solutions INC

0 Helpfuls