xMatters-provided integrations and steps

Not Yet Reviewed

This is not an entirely positive post so I feel that I need to start by saying that I do absolutely love the platform. I love the flexibility it provides and how it enables me to achieve so much.

That said ... I am concerned about some of the integrations and steps that are provided by xMatters. This has come back to the fore for me recently as I've had to build some new workflows to integrate CloudWatch, Jira Server and StatusPage together.

xMatters provides a Jira Server integration which, out of the box, has very little to configure. The documentation is very clear on how to trigger the integration from Jira workflows and there isn't much to do to get it set up. So far, so good. However, on the very first test of triggering the workflow from a new Jira ticket, the workflow fails.

Why? Because the workflow has some properties that, instead of being free text fields, are lists of approved values. Why is that a problem? Because Jira is also flexible and allows you to configure these values to be different.

So I've had to convert the integration to a custom workflow and replace all of the fixed lists with text fields. Validating values from Jira seems to have no purpose within the workflow. All it leads to is xMatters users having to convert the integration.

The StatusPage steps provided by xMatters are similarly limited. There is no support for specifying the components affected by an incident and although there are some solutions provided by the community, what I've discovered is that StatusPage doesn't handle the incident "correctly" unless you specify the affected components in the incident itself when it is created. So that has meant turning the xMatters-provided step into a custom step and modifying the code.

These are two examples where the functionality provided by xMatters could be so much better if the steps/integrations were just a little bit more flexible. It concerns me that, at almost every turn, I'm having to take the provided features and customise them - something that I feel so many other people have ended up having to do as well, resulting in duplicated effort.

The Jira Server integration is easy for xMatters to fix - just turn the lists back into plain text fields.

I'm happy to share my StatusPage customisations back to xMatters to avoid others repeating the work but I do fear that it is the tip of the iceberg. I am concerned that I'm not alone in taking the bits and pieces that xMatters provides and then extending it to actually do what is needed. If that is correct, would it help xMatters if there was a discussion thread where people could post which xMatters-provided integrations/steps need improving? Or is everyone already aware of the problem and I'm not looking in the right place for the enhanced bits and pieces?

Thank you for reading this far. Now I'm off to extend the Jira Server integration so that I can assign the Jira ticket to the xMatters agent who acknowledges the event because who doesn't need that feature!?!?!

 

 

0

Comments

3 comments
Date Votes

Please sign in to leave a comment.

  • "Now I'm off to extend the Jira Server integration so that I can assign the Jira ticket to the xMatters agent who acknowledges the event because who doesn't need that feature!?!?!"

    I can't edit my original post so I need to apologise for this comment. The integration does (according to the documentation) support issue assignment to the user that responds with "Accept". It just isn't working for me at the moment and that's because I hadn't read the documentation carefully enough. I've had to add a Jira Username custom field and populate that. Still not working but that is probably still down to me and not the integration ... hopefully.

    0
  • Hi Philip,

    Feedback in all its forms is precious so thank you for taking time to express some of your frustration points in setting up this integration.

    I'll bring this to the attention of our Product Management team so they can review internally whether or not as you say these fields would be better off as free-form text fields or something else.

    I would imagine there was a reason for the design decisions that came with this built-in setup, albeit I am not aware of what those are at this time. With that said, you absolutely did what I would have done too and cracked the workflow open, configured the fields as would make sense in my Jira ecosystem and tested to be sure values were passing appropriately to each property.

    If you are still having issues with using the Accept feature then feel free to pass that on so we can keep looking at it with you.

    Happy Monday!

    0
  • To add to Francois' response, we'll see about updating the documentation to add a few reminders about the custom field along the way - it's easy to miss. Thanks for the feedback. 

    0

Didn't find what you were looking for?

New post