You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
Hi all,
we have Team A, who's service A is always affected by incidents which occur on service B. Sometimes they have to be involved as they are part of the resolution process, sometimes they only need to be informed because their service is affected.
After some testing it seems to me that the alerting is pretty much the same, no matter whether Team A subscribes service B or whether they are set as responders in service B.
Which implementation would you choose and why? Are there any technical or processual "consequences" when choosing one or the other way?
Thanks and best regards,
Stefan
/edit: as far as I understand, service subscriptions are only featured in the Enterprise Plan. Is the option to be added as responder also possible in the Standard Plan? (as we're on Enterprise trial, I can't check it myself)
Hi @Stefan Draber ,
"Which implementation would you choose and why? Are there any technical or processual 'consequences' when choosing one or the other way?" - There aren't really any consequences of using either. Like you mentioned, both work very similarly. But there is the limitation that service subscriptions are only featured in the Enterprise Plan.
Multiple responders can be added to a Service under the Standard plan - so that would be the best option under this plan. Bug again, either would work under the Enterprise plan as well.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.