Impact of not subscribing to SAM pro on Service Graph Connector for TaniumIssue After thoroughly examining the ServiceNow documentation you understand that 3 Data Sources come with Service Graph Connector for Tanium: https://docs.servicenow.com/bundle/washingtondc-servicenow-platform/page/product/configuration-management/concept/cmdb-integration-tanium.html The docs also state that you need to have the SAM professional plugin (com.snc.samp) installed to have the Software Usage Data Source appear. And so, it doesn't exist as SAM Pro is not part of your licences. However, as there is no mention of SAM requirement for population of the cmdb_running_process table.You would like to know whether you can proceed with mapping to this table without SAM Pro license. If not, is there a known workaround for this feature? As you use an account with read-only rights, if you decide to activate it, will it still cause issues?CausePopulation of cmdb_running_process was part of ADM feature for SG-TaniumSN, but this is NOT currently supported, as it can cause breaking changes in the Customer's Tanium instance.So there isn't a tie/dependency on SAM Pro, but in general it is not a currently supported feature. The customer should not try to enable it.Note that for SG-TaniumSN the installation of SAM Pro determines which table(s) are populated for software installs. (This is consistent with other SGCs.)If SAM Pro is installed, then software installs are inserted into cmdb_sam_sw_install.If SAM is not installed, then software installs are inserted into cmdb_ci_spkg and cmdb_software_instance.ResolutionThe running_process table will get data using SG-Tanium Applications data source but as of now its disabled.So this is expected running_process is not getting inserted. It could (and did) cause major problems in our customer's instances when used.That is why it is currently disabled.You could encourage your customer to reach out to Tanium on this, as we are blocked on our side.But are currently blocked & waiting for Tanium to review this, and there are no workarounds as we can or should offer, as it can(& did) cause issues when we tested. So, we do not recommend this approach regardless.