MSIM Teams Create and Renew Subscription SubFlows are failing

[Charlotte Pakes]

We have the Teams integration for MSIM.

This works correctly to create the Teams and the Channels.

However the Renew Subscription and Create Subscription Subflows are failing with Resource not found when the Scheduled Job tries to renew the Subscription.

So initial creation is successful, but after an hour when it attempts to renew the subscription it fails. Then the next time it runs and attempts to recreate the subscription it fails with the same issue - it cannot locate the resource even though ServiceNow originally created the Team and the Channel successfully itself.

Anyone else encountered this? I have a support case open.

Also - not sure why it is 60 minutes when Microsoft documentation seems to suggest subscription should be valid for 3 days?

[Aravind2799]

Hi Charlotte,

The 60-minute window is most likely intentional. Microsoft Graph does allow Teams message subscriptions to last up to about 3 days. However, Graph requires a lifecycleNotificationUrl on any Teams resource subscription whose expiration is more than one hour out. The OOB integration appears to keep the expiration at 60 minutes to avoid that requirement, which means it depends on the scheduled job renewing reliably before the subscription lapses.

That points to a likely explanation for the first failure. A PATCH to /subscriptions/{id} returns 404 Resource not found if the subscription has already expired and been deleted on Microsoft's side. If the renewal job runs at or after the 60-minute mark, for example a 60-minute schedule interval with some processing delay, it will try to renew a subscription that no longer exists. I'd check the job's interval against the stored expiration time. The renewal needs to land comfortably before expiry.

The recreate failing is the more telling part, since a POST to /subscriptions shouldn't 404 just because the old subscription is gone. A few things worth checking:

1. The actual request in the outbound HTTP log. Look at the exact resource path being sent, /teams/{team-id}/channels/{channel-id}/messages. Channel IDs look like 19:xxxx@thread.tacv2, and an encoding problem or a stale or incorrect team/channel sys_id mapping will produce a 404. Also confirm it's using the team (group) ID that Graph returned at creation time.
2. Test the resource directly with the same credential. Run a GET /teams/{id}/channels/{id} through Graph Explorer or Postman using the same app registration and token flow ServiceNow uses. If that also 404s, it's an access problem, not a subscription problem.
3. App registration permissions. Confirm ChannelMessage.Read.All (application) is granted and admin-consented. If the integration uses delegated auth, check whether the service account is still a member of the team. Teams/channel creation can succeed under one permission set while message subscriptions require another.
4. Existing subscriptions. Call GET /subscriptions with the app's token to see whether any subscriptions still exist for that channel, and whether their IDs match what ServiceNow has stored.

If the outbound log shows a well-formed path and the direct GET works, that's useful evidence to add to your support case. It would point to the subflow building the request incorrectly on the renew/recreate path, rather than a tenant or permissions issue.

Thanks

Aravind Panchanathan

---