Nick Haller Atlassian Team

Hi @Alper Cugun , The Email integration would probably be the easiest. You could share the integration's address with the facility, and an alert can be created anytime an email is received. Otherwise if you use other ticketing tools like Jira, JSM, Zendesk, etc. - those would be great alternatives.

It's not to say that you should not / cannot user Services and Incidents - but again - realistically these should be treated as serious service disruptions and outages. So creating an incident for ALL Datadog alerts does not make much sense to me. 

Yes, that should be possible - but I don't necessarily think it's needed. Creating an incident for all of these types of Datadog alerts is somewhat of an overkill in my opinion. This can realistically be accomplished just using Opsgenie alerts - unless you have a use case to create an incident for all of these?

Hi @Dave Beaudoin , Outside users should still be able to preform /genie commands on an alert, or select the default buttons available within the Slack alert - as long as your do not enable the Require Matching a User option: User will have to connect their Slack accounts to Opsgenie using /genie connect command if that is…

Hi @Alper Cugun , Opsgenie has a prebuilt Datadog integration that can create alerts to notify your Opsgenie users. Best practice is sending alerts to a team since a team's On-call tab can manage which users are notified, as well how the alert is escalated is no action is taken. This can be done through routing rules, and…

Hi @Carol Saldanha , Logs are only retained in the UI for 13 days. Opsgenie does have a Logs API which shouldn't have a limit on pulling past logs, but this in only included with the Enterprise plan at this time.

Hi @Andrés Enrique Cárdenas , You should be able to correct this in JSM by navigating to the Settings menu → Issues tab → Screens tab → Configure the same project’s screen that is configured in the integration’s action mapping section: Add any fields to this Screen that appear in 400 error (labels, summary, description,…

It's not possible to entirely remove the Source (or any other default alert field) at this time.

Hi @Quique , At this time it's not possible to disable the alert created by the Forwarding Rule. But there should be a few ways to avoid your users from being notified of these alerts. You could configure an Alert Policy that modifies the forwarding alert, and removes the responders that are added. Might look something…

Hi @SebManGK , You can edit what parses (or does not parse) in the Source field within the integration's Advanced tab. Note - this tab is only available under the Standard and Enterprise plans / JSM/O Premium and Enterprise plans: If you do not have access to this tab, I believe you can also edit what parses in the Source…

Hi @Techx_Huy_Tran , You may need to clarify more on what you are hoping for. It sounds like you are referring to an Email Integration, and needing to extract your customers which are parsing in the Subject field. If that's the case, this Community Article should help with extracting custom fields or pieces of data in an…

Hi @Nicolas Helmer , Opsgenie used to have mass notification functionality, but not longer does like Informacast or other similar tools offer. Closest thing to that nowadays would be through incidents - specifically notifying stakeholders. Important to note that stakeholders are only available on the Enterprise plan…

Hi @John , Under the Statuspage integration's For other Opsgenie alerts section, you can configure a filter to trigger the creation of an incident in Statuspage when the condition(s) match:

Hi @Nicolas Helmer , This Community Article might help with mapping priorities: How to Map Alert Priorities in Opsgenie If ServiceNow's priorities differ from Opsgenie (especially if there is no numerical value 1-5 being sent in the payload), then the dynamic {{priority}} will not match and Opsgenie will default to mapping…

I'm not entirely sure what your use case is to filter on the Alert Actions. If you do not want these actions taken on the alert posted in your Slack channel, then you can simply unselect them under the checkboxes of the integration here: By default, these are included to send to the Slack channel you have configured in the…

Have you tried either of these: {{customFields.customfield_10072}} {{customFields.customfield_10072.name}} ^ Note they do not include _parsedData (which is instead interpreted as _payload to extract this into the alert).

Hi @Marco Liporoni , If possible, it might make sense to share some screenshots of your on-call schedule / rotation, as well the configuration of your team's On-call tab. Although you may have a rotation that is restricted to days / times, an alert will still flow through the team's On-call tab to notify users through…

Hi @Tu Lan , Those alert actions refer to what can be found here on an alert: Highlighted above are a few custom actions that can be added by an integration or through an alert policy: For example with Slack, if I were to filter on the alert actions with a similar filter to yours using regex, this would match:

Hi @Carol Saldanha , It's not currently possible to edit the predefined Schedule Start / End notifications, but we have an open feature request for this functionality you can follow, watch and vote for here: As a user I would like to configure the Schedule Start/End Notifications

Hi @Elzha Odie , I believe we have spoken in another Community Question about the same issue. Please try both of these suggestions below to extract that custom field into the alert, and let us know whether or not they work: {{customFields.customfield_10072}} {{customFields.customfield_10072.name}}

It's only possible to extract the fields when the issue is created. The field you highlighted in your screenshot differs from the one I had suggested above, and includes "_payload" Please try with these: {{customFields.customfield_10072}} {{customFields.customfield_10072.name}}

This Community Article should help with extracting that: How to Extract Custom Fields and Data into an Alert If I had to guess, you may need something like this to extract that field into the alert: {{customFields.customfield_10072.name}}

Hi @Michael Easlick , That should be possible through a few rotations where one represents the weekdays, and the other represents the weekends. For context below: A - User 1 B - User 2 C - User 3 D - User 4 E - User 5 F - User 6 G - User 7 Both of those rotations along with the final schedule might look something like…

Hi @Shubham Yadav , If the integration is global or not assigned to a team, you can configure this under the Advanced tab of an integration. Important to note this tab is only available under the Standard and Enterprise plans (or the JSM/O Premium and Enterprise plans): All integration actions are processed in an order of…

Hi @Kistie Simmons , When viewing a service under the Service tab, you can remove the Owner team here: Once removed, you'll then be able to reassign the service to another team:

Hi @Simon K , A feature request like this one? https://jira.atlassian.com/browse/OPSGENIE-113 If you have other questions related to something else, it might makes sense to open another Community questions, or a ticket with Opsgenie support.

Hi @Simon K , Have you tried to sending the JSON to Opsgenie with Azure Activity Log event schema instead of the Common alert schema? I believe in the past customers have tested with both options, and the activity log schema seemed to work better for the both the Azure Service Health and Resource Health integrations.

Hi @Bailey Hecksel , There's also the option to assign your users a custom role that allows them to See All Alerts:

Hi @Kim Barry , Since the responder field is an array like tags, I believe Contains or Matches (regex) should be either of the two options selected when filtering on the team/responder. I had success filtering on the actual name vs. the ID though. For example: The order of your notification rules might matter as well since…

Hi @Krista Schlumpberger , Are you on-call in that team's schedule? Your workflow looks configured correctly - and I would suggest routing to the escalation vs. the schedule. Routing directly to a schedule essentially skips over the escalation entirely and only notifies the on-call user(s) - while routing to an escalation…