Trigger being disabled when triggered

Good day all,

I have run into an issue. Created the below Trigger in Dec and tested it successfully, it triggered the workflow.

{
"id": "dc323ea5-0dfc-4598-8e0b-0773acee57fc",
"name": "Trigger Workflow on ACW",
"topicName": "v2.detail.events.conversation.{id}.acw",
"target": {
"type": "Workflow",
"id": "3d84ca5b-ef95-4089-b644-23728d07b557"
},
"version": 10,
"enabled": false,
"matchCriteria": [
{
"jsonPath": "direction",
"operator": "Equal",
"value": "INBOUND"
},
{
"jsonPath": "mediaType",
"operator": "Equal",
"value": "VOICE"
},
{
"jsonPath": "wrapupCode",
"operator": "Equal",
"value": "2262c266-4e83-431d-a17f-cd32bbdd21b5"
}
],
"description": "Trigger on ACW (wrapup)",
"selfUri": "/api/v2/processautomation/triggers/dc323ea5-0dfc-4598-8e0b-0773acee57fc"
}

I update the Trigger to Enable it again, but as soon as the Trigger matches it gets disabled again.

Anyone have a clue why this is happening?

Rolled back the Workflow to version where it was working and now the trigger is not getting disabled.
Workflow triggering again. Not sure why as nothing changed on the flow except the email htmlBody of the agentless email.

O well.

Hello Dewald,

I know you have already marked the thread as solved, but I just wanted to give you an idea of what could have caused this issue.

I had this happen to me once, and it took me hours to understand why... This was caused by the name of a new variable that I added to the Flow.

Basically, the variable's name was the same name of one of the properties on the Event that triggers the Workflow.

Normally, if you want to use one of the properties from the Event, you create a variable with the same name, and set it as an Input variable. Right?

Well... if you create a variable with the same name as one of the properties, and don't set it as an Input variable, this issue happens.

I noticed that you mentioned the only change in the Flow being related to emails.. Did you create a new variable as "Flow.subject", or "Flow.addressTo" or "Flow.addressFrom"?

Those are some of the properties on the event, and could be the issue.

Anyway, just wanted to give you an idea to check!

Really quite poor that a matching variable name from the schema would cause that when NOT set as input to workflow. That should not be happening.
Best practise to use other names but that should not be a cause of failure in GC design.

Yeah, I absolutely agree... It took me so long to realize that was the issue... Makes no sense at all.

If you haven't already that should really be reported as a customer care case in hopes they either correct it, put an error/warning message around it, or add it to the documentation at the very least.

Hi everyone,

I agree with Eos. This should be opened as a care case. They can route this to the engineering team and hopefully fix this.

Also adding in @Richard.Schott. He is the product manager for process automation triggers and might be able to provide some more guidance.

Thanks,
John Carnell
Director, Developer Engagement

I didn't exactly report it.

But I had a case open when my trigger was being disabled, and they were helping me investigate it.

In the end they were aware that the issue was caused by not setting the variable as an Input variable (Even though I didn't want to use the value from the schema property)... So I just changed the variable's name and the problem was solved.

They are aware of that... But I don't know if they are planning to change this at any time, or add anything to documentations.

I'll review our documentation, including the conditions under which a trigger might be disabled, and see what we can do to provide some more clarity here.

There are also some planned efforts to provide more robust troubleshooting/customer accessible logs for triggers, and Architect/flows in general (these are separate, but related efforts), which should be releasing later this year.

1 Like

@Richard.Schott
Is there ANYTHING I can see to debug failing triggers right now?
I have a trigger failing at a final stage in workflow (using SET Conversation (participant data) to create debug messages).
The final part is calling the customer API via an action.
That API action works every time I TEST it and use elsewhere.
However in workflow that is triggering the failure path (again using Set Conversation object to show in Participant data) for conversation Id.

I have checked, double checked and triple checked.
The schema properties I am using from the user.end topic schema are in workflow as input variables in exactly the same case and spelling.
As to reply above made about name clash, NONE of my other state variables clash with any of the named properties shown in the user.end topic schema.

Where had this before (on topic acw), it was one of the trigger properties causing a fail, wrapupNotes even though shows as schema property.
However the only way you can test this is to

  • Copy workflow to new version, remove a field...
  • Find trigger ID and delete it (quicker than patching it!)
  • Find new flow ID, update create trigger with new workflow ID and create
  • Rinse and repeat for each field until find culprit... even though only properties I have are ones shown in schema

This is consuming so much of my time and pretty sure it's failings in the trigger to workflow schema processing in GC.
Why can't the Audit viewer show the errors and cause?
Why is the details.errorcode in workflow a generic "INVALID_SCHEMA" :frowning:

Hi Simon,

Can you provide the trigger ID (The GUID) and the Genesys Cloud region that your are working in? I can probably give you more information about what is going wrong.

--Jason

Sent you in direct message
Thanks
Simon

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.