ServiceNow SAM Pro enables customers to perform software reconciliation for traditional software vendors. Additionally, it supports integration with SaaS vendors, allowing organizations to track subscription usage and entitlement — such as the number of active Adobe Cloud subscriptions.
When following the standard setup steps for Adobe Cloud integration (as outlined in the ServiceNow documentation: “Integrate Adobe Cloud using OAuth Server-to-Server credentials”), the integration typically works successfully the first time.
However, after a development instance is cloned, the integration may stop functioning — specifically, subscriptions may no longer be downloaded.
This issue usually stems from missing or invalid data that was originally entered during the initial installation. During the setup process, several key attributes are required to establish a working connection. These include (but are not limited to client id, organization id, etc.):
Talking to your Adobe admin will help tremendously to be able to perform the Servicenow setup instructions.
As mentioned, after cloning, the “Import Adobe User Subscriptions” job fails, showing it in status.
After opening the job result in this case SJR0025527, the message is not helpful:
As part of the troubleshooting, I tried to recreate the token, double checked client id and client secret but that didn’t help. I started checking the table that stores the subscriptions profiles: samp_sw_subscription_profile. I figured out the one parameter was missing: Technical account id. I noticed that since I took screenshots of the profile before the clone and then I reviewed it carefully.
For security reasons, I was unable to overwrite the Technical Account ID directly from the list view. Additionally, I wanted to avoid creating a new integration profile. As a workaround — though not recommended — I modified the XML file to update the profile and manually insert the value for the Technical Account ID field.
Later, I reloaded the subscription profile XML file. After that, the daily jobs resumed functioning as expected, and subscription records began populating in the samp_sw_subscription table. The Subscription Profile field in this last table points to the corresponding integration profile, which helps confirm that the subscription download job is working correctly again!
ServiceNow SAM Pro enables customers to perform software reconciliation for traditional software vendors. Additionally, it supports integration with SaaS vendors, allowing organizations to track subscription usage and entitlement — such as the number of active Adobe Cloud subscriptions.
When following the standard setup steps for Adobe Cloud integration (as outlined in the ServiceNow documentation: “Integrate Adobe Cloud using OAuth Server-to-Server credentials”), the integration typically works successfully the first time.
However, after a development instance is cloned, the integration may stop functioning — specifically, subscriptions may no longer be downloaded.
This issue usually stems from missing or invalid data that was originally entered during the initial installation. During the setup process, several key attributes are required to establish a working connection. These include (but are not limited to client id, organization id, etc.):
Talking to your Adobe admin will help tremendously to be able to perform the Servicenow setup instructions.
As mentioned, after cloning, the “Import Adobe User Subscriptions” job fails, showing it in status.
After opening the job result in this case SJR0025527, the message is not helpful:
As part of the troubleshooting, I tried to recreate the token, double checked client id and client secret but that didn’t help. I started checking the table that stores the subscriptions profiles: samp_sw_subscription_profile. I figured out the one parameter was missing: Technical account id. I noticed that since I took screenshots of the profile before the clone and then I reviewed it carefully.
For security reasons, I was unable to overwrite the Technical Account ID directly from the list view. Additionally, I wanted to avoid creating a new integration profile. As a workaround — though not recommended — I modified the XML file to update the profile and manually insert the value for the Technical Account ID field.
Later, I reloaded the subscription profile XML file. After that, the daily jobs resumed functioning as expected, and subscription records began populating in the samp_sw_subscription table. The Subscription Profile field in this last table points to the corresponding integration profile, which helps confirm that the subscription download job is working correctly again!
