Alerts with different priorities based on auto-attendant key press in JSM Incoming Call

Hi @Gabriela - LeanZero

Thank you, your reply was partially helpful. I've voted on OPSGENIE-266. I also found this related community thread  that may be relevant.

Based on what I see, the functionality I was expecting may not actually be supported

- the Body field contains no information about the pressed key. Here is the relevant excerpt from the Jira Admin → Audit Logs to illustrate the issue:
_result: alertAction: create
integrationName: JSM-TWILIO-555555
integrationActionName: Phone Alert - Key 1
_incomingData:
_parsedData:

Type: phone

alertSource: com.opsgenie.client.model.dto.ActionSourceCustomDto@7115473d[ domain=integration, sourceType=IncomingCall, sourceName=JSM-TWILIO-555555, incomingDataId=7f75267a-a8df-416a-b615-4xxx, sourceSubName=Phone Alert - Key 1, customSourceName=<null>, actorUserId=<null> ]
delayIfDoesNotExists: true

To: +555555
From: +444444

Body: null
Type: phone
integrationType: IncomingCall
integrationName: JSM-TWILIO-555555
integrationId: e10115e9-9fd4-487f-a149-3xxx
To: +555555
From: +444444

As you can see, Body is null, which is exactly what my original question was about.
Regarding the filters page — yes, I did review it. The problem is that it does not document the possible values. For example, for Type I can see that phone is valid, but what other values are supported (e.g., DTMF key, etc.)? Likewise, what values can appear in the Body and other fields?

At the moment, my only option is to reverse-engineer this from the audit logs, which is not sustainable.

KR,
Andrei

Hi @AY3. Thanks for posting the log, that is better evidence than anything I had, and Body null answers the original question.

On your real one, the page that documents the variables is not the filters page, it is "Work with alert properties". It sits at the URL /docs/work-with-dynamic-properties/, which is a decent part of why you could not find it. Its point is that the property set is specific to each integration and that the filter condition drop-down is where that integration's set is listed. So the drop-down is the enumeration. Thin, but that is what there is: I have not found a per-integration value list published anywhere else, and that is what leaves the filters page reading the way it does.

The part worth ten minutes is further down the same page. Anything the integration sends that is not offered as a draggable property is still reachable as {{_payload.whatever}}, nested paths included, alongside {{_headers.x}} and {{_url.x}}. That page also carries the list of integrations that do not support alert properties, and incoming call is not on it. Put a probe in the Message of a rule with no conditions and read the raw incoming data off the alert itself rather than the Jira audit log. I have not had a Twilio number to try that against, so treat it as a test rather than an answer.

The key does exist, only after the alert does, in the activity log. If you want it automated: GET /jsm/ops/api/{cloudId}/v1/alerts/{id}/logs, then PATCH the same alert's /priority. Whether that line is written by the time a callback fires, I cannot tell you. Untested here.

https://support.atlassian.com/jira-service-management-cloud/docs/work-with-dynamic-properties/