Hi,
I was going to post this as a support, but I'd like to get some feedback from other users as well as when it comes to administration of xMatters, I find it very, very clunky. Here are my main pain points, please feel free to add or expand on them as you see fit:
Deleting users: When trying to delete a user - there are several problems. If the user has any active subscriptions, you cannot delete them. This seems strange - I'm trying to delete the user as xMatters is available from anywhere and these users are no longer with the company and I do not want them to have access. I have just tried this and the only way around this is to log in as them and delete their subs (more on this later). However, if a user is an 'admin' you cannot log in as them. To quickly resolve this issue, I just unchecked the 'active' box in their account. Bad idea. I removed their admin role from their profile so I could log in as them, only now I can't log in as them because their account is no longer active. Site admins should be able to delete users, regardless of their current subscriptions.
Subscriptions: To be able to modify a subscription, you have to log in as that user. It would be far better if group supervisors could achieve this from their own account as they cannot log in as other users, so it's down to an administrator to do. This is problematic when it's multiple users as you have to log in as them, edit the sub, log out as them, log back in as yourself, go to the next user and repeat.
Now, you can have the managers of the group create a subscription and share it with their team - but by default, it does not subscribe them to the shared sub. Some of our executives are never going to log into xMatters, so it makes more sense to be able to control things like this from an admin or group supervisor account. Even more strangely, if you share a subscription with a user, but do not give them 'subscribe|unsubscribe' permisssions - they can see the subscription in their account, but they cannot turn it on. Does that mean you would share the sub, wait for them to activate it, then turn the option to sub|unsub off? This whole process needs a lot of work. I understand that there's going to be a concern about someone subscribing people without their permission, but why not do it like the 'text message device' setup and email the user to tell them about the subscription and then have the subscription turned on by default and the email asking them if they want to 'opt out'.
Logging in as User: This one is pretty simple, when I go to a user account and choose to log in as them, when I log out of their account, xMatters should just return me to my account instead of having me log back in again. Or at least an option to 'return to original user'. Now, in saying this, if some of the above issues were fixed, I'd have less reason to log in as another user - but still, it makes far more sense to go back to the original account instead of being kicked from the system completely.
I think that's about it for now. Apologies for the rant, I've been working on these for a while and I would like to see what other users have to say about this, if they have better solutions to the problems I'm facing - and also for the xMatters devs to take these 'enhancements' under consideration for future releases.
Thanks,
David
Comments
Please sign in to leave a comment.
Hello David,
Your points are well made. We'll go over them and see what we can do on the product side. There are some challenges with merely deleting a subscription due to the sharing options, but there are probably some ways around that we can query our customer base for what you feel is reasonable behavior.
One thing I would point out is that users with elevated permissions can modify subscriptions for other users. You should a see drop down in the Subscriptions screen and if you select Manage Subscription (I am operating from memory, I'll validate later) you can see other user's subscriptions in the system. You can then use our search screen to search by a subscriber name to filter the view down. That might help you get to closer to where you need to be.
Thank you for the feedback, and hopefully other customers will chime in with help or other nits for us,
Doug
Hi Doug,
I don't see that option in my subscription screen. The drop down options are 'owned, 'subscribed' and 'shared'. If a user creates their own subscription - neither of these options are going to show other users subscriptions. Maybe I'm looking in the wrong place?
David,
You are in the right place, but are missing a permission that will open up the option. We'll chase down what you need and update this thread.
Doug
Hello David,
I poked around at this some more... there are two permissions that can be used to provide view or edit options for all subscriptions to a role. The permissions are:
ability.act.EditAllSubscriptions
ability.act.ViewAllSubscriptions
A user with a role possessing those capabilities will see the Managed option in the dropdown, allowing them to see subscriptions not owned by them. And if they have the ability.act.EditAllSubscriptions role the user can also edit or delete the subscription.
I don't believe you can edit roles directly in your system, but your CSM can make these adjustments for you. The trick here is associating the permissions with a reasonable role, because they obviously give users some superhuman strength (and with great power comes great responsibility - sorry I couldn't resist a Spiderman quote).
Bonus item: if you create a subscription for an end user, you will be the owner of the subscription. And because the end user isn't the owner, they can't edit their own subscription. That is great for "assigned subscriptions" where you are forcing the user to get messages, but what if you want the end user to be able to edit their subscriptions? You can change the owner of subscriptions by going to the top level Subscriptions screen, and then checking the checkbox next to each subscription you would like to change. When you check the checkbox, two new options will show in the toolbar: one to Delete Subscriptions, and another to Change Owner. Using this feature the subscription creator can change ownership over to the end user, allowing the end user to now own their subscription.
With all of that said, I am sure there are some other usability things that we can look at. But hopefully this helps you along.
Doug
Thanks Doug, I will speak to my CSM about those abilities. As for the sharing of subscriptions - we do use that and I appreciate the bonus tip - the problem with sharing subscriptions as far as I can see though is that when you share them, they aren't active for that user unless they go and activate them, which is something I noted in my original post. Subs that are shared should be activated automatically with an 'opt out' email/text like what happens with SMS devices when they are first set up.
Thanks again,
Your friendly neighborhood xMatters user
You bring up sharing, but that wasn't what the tip was about,... the tip is about assignment. Assignment puts the user in as a target - they will get notified. Sharing makes the subscription available to,other users or roles so they can opt into what they want - and they won't get notified unless they opt in. They are two different mechanisms to solve two different problems.
Hi Doug,
This is the first time in this thread that I've seen anything about 'assignment' so can you tell me what feature that is, where is lives.. or point me to a resource online that I can read about it.
Thanks,
David
When you define a subscription form you have a section where you can define the Roles that can Subscribe. That powers the "+" button on the subscriptions screen dictating what subscription forms a user is allowed to use. When a user creates a subscription from a form, they are by default the subscriptions Owner.
Another setting, Subscribe Others, exists at the top of the subscription form design view. When checked it allows a user with access to the form to subscribe other people to subscriptions using the form... in essence assigning the subscription to them (I believe we are calling this "managing" now, but have used the term "assigning" in previous UI versions). The actuals users that can be assigned a subscription is driven by the role-on-role definitions in the system. For each role you can say if that role is allowed to manage the subscriptions of users in another role (this screen is available to our CSMs to adjust per your requirements).
As mentioned, when a subscription is created, the person using the form is the owner. If they don't adjust that, and they assigned/managed another user as a recipient of the subscription, the subscribed user can't edit the subscription. However if they want to change the owner they can change it using the bonus tip previously mentioned.
Sharing a subscription allows for an in between behavior. When you share a subscription, you are defining the matching rules and routing preferences, and then making it available to other users to opt into or out of. But those users can't actually edit the matching rules or routing preferences. What they get is a very easy to manage list of subscriptions to opt into or out of, fine tuning what are in essence subscription channels.
Those are the three main modes I see our product as currently supporting. Over time we expect to actually break up the matching rules (what we will call a feed), and the routing rules (what will be the actual subscription). At that time users can easily opt into a feed, and then set their own routing options (e.g. User1 want email only, and User2 wants email and SMS). We haven't started work on this, but are looking to do it as we invest in our own customer communications processes next year.
Our Technical Publications team is reviewing this thread and the existing help resources to see what we might do to expand on these concepts. Again, thank you for your feedback.
Hi Doug,
I didn't even know about the 'subscribe others' checkbox and it does exactly what I wanted from a subscription perspective, so this is great! Thanks!
@david: This is great stuff. I truly appreciate that you took the time to provide us this feedback. As Doug mentioned, we'll be clarifying a bunch of things in our documentation over the next Tech Pubs sprint or two.