So I have been experimenting with triggers and have them firing, I get they are in their infancy but finding the API Explorer section is missing some KB / FAQ around this, so thought I would ask here.
Also, some suggestions. I looked at the Ideas AHA portal but do not see a category for API related Ideas?
Questions
Is there any monitoring tool for Triggers, not found anything in PA section about triggers or around the UI?
(I know I can call trigger apis but looking for something UI or alerting)
What causes a trigger to set to disable (Enabled: False),. I understand its an error, but what thresholds cause this?
Is there a limit on triggers/workflows I need to worry about. Current project has a requirement to fire API calls to customer system for call start/end, agent start/end, Abandon notification etc. (Triggers appear better option than Notifications api which is clunky)?
Suggestions
Add TopicId to all the output schemas, so I can create a "smart" worflow that handles multiple topics. This also requires the next suggestion to be adopted as well though;
Allow Input vars to the Workflow that do not exist, set them to a default like NOT_SET. This would allow "smart" workflow to not fail with missing variables from different topicIds.
Need some form of trace/logging. I looked at Audit area but see nothing to assist in understanding why a Trigger failed (usually the workflow). Adding participant data at different steps is really a poor workaround at present.
Add webhook target to pass all schema fields to an API endpoint, bypass workflows.
Add an API endpoint to Enable a trigger again, the PATCH requires half the fields again!
Hope above makes sense
I can see lots of uses for triggers and hope this area keeps improving.
Not at the moment, but that is a near term development initiative to create better supportability tools for triggers (this is generally a larger platform initiative that we're tying into with Triggers).
Enabled is an admin/developer controlled attribute. There are no automatic settings that would disable a trigger on you at this time. If we were to implement such automation, that would be explicitly documented/communicated.
The limits for triggers are documented here: https://developer.genesys.cloud/organization/organization/limits#event-orchestration
The main one to be concerned with is the entity per hour limit (currently set at 100). An entity is the {ID} referenced in the topic, mainly conversations. This limit is mainly in place to prevent circular logic (an attribute update triggers a workflow that updates an attribute that triggers a workflow that updates an attribute....).
Suggestions:
noted.
more of an Architect suggestion, but I'll pass it along
Q2 - A triggers gets set to enabled false by something in GC, as mentioned I am assuming problem in flow. This is definitely happening.
S2 - Architect or Triggers, or both, it would make huge difference to handle input variables to flow that may not exist because the workflow is handling multiple topics.
S3 - Assume no other approach then, other than setting participant data?
S4 - My point was the put expects multiple fields (nearly all of them), rather than a Trigger ID to an API with /?enabled=true type call. Found easier to delete trigger and re-add than patch it!
Is this the right forum to make suggestions, as mentioned I do not see an API category in the AHA site?
Is this the right forum to make suggestions, as mentioned I do not see an API category in the AHA site?
No, they prefer Ideas and suggestions go through AHA and just pick the category to which the API corresponds. Analytics for example, or in your case Self Service And Automation.
I had to double check with the development team. They informed me that there are a few scenarios where a trigger is disabled, centered around "it would just never work" scenarios (the main one being the workflow ID the trigger is supposed to be invoking doesn't exist). If we automatically disable a trigger, an audit event is created indicating when it was disabled, and include a reason as to why it was disabled.
I'll discuss with the team the possibility of including a PATCH operation, although I'm not entirely clear how that would work with the version requirement (which generally requires you to GET the current version, then increment it along with your modified property in order to send the PUT).
Regarding your second question, I also noticed that happening in the past.
And after some troubleshooting I managed to find the reason why (At least for my case).
But to summarize, in my case it was getting disabled because of the name of a variable in the Flow.
The variable had the same name as one of the properties on the Event Schema of the Topic being used in the Trigger (But I wasn't aware of this, because it was a property I wan't using at all), and since I didn't even know it was a property in the event, I didn't set the variable as an Input variable. Because of that, the trigger gets disabled, and just changing the variable name fixed the issue.