cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
320
Views
0
Helpful
0
Replies

Cisco Finesse Workflows - Call Type Condition through Config APIs!

I figured out how to get a call type condition to apply to a finesse 12.5 workflow by using the config APIs. It seems an order of magnitude easier than rolling a custom gadget, but you do need to do it through the APIs and not the front end.

I suppose part of my posting this is to also get a read on if this is a bad idea or if some of you more experienced devs have any thoughts. I know the gadget route isn't that bad, but some colleagues seemed unhappy with the idea of rolling a gadget and this is crazy easy and uses all the plumbing workflows already has. It is also all documented via the API docs, so it's not like it's an undocumented feature, it's just unsupported in the finesse desktop. 

First Attempt - Custom TriggerType

I'm relatively new to uccx and helping support a bu roll out a page pop. The goal is to do this as cheaply as possible as a proof of concept and I figured out a crafty way to limit page pops to inbound calls using the config apis.

All I wanted was for the workflow to trigger on an inbound call to the agent, when the agent answers. I have trolled the forums and the answer was always "custom gadget" but I decided to give workflows a quick go and read through all the API docs for them. I tried out some of the APIs in Postman with my authorization set to a basic auth with my finesse admin credentials in a sandbox and then started experimenting.

My first inclination was, "I can configure a custom TriggerSet with just the call types I want". after read the workflow configuration apis. NOPE, can't have any other trigger types than the ones provided by the system. Why even have docs on TriggerSets when you can't even use them? I did see that SYSTEM was the only valid TriggerSet Type in the docs but I was really hoping that was just a supported in the front-end vs unsupported in the front-end kinda thing. 

 

 

<TriggerSet>
    <type>CUSTOM</type>
    <name>INBOUND_CALL</name>
    <triggers>
        <Trigger>
            <Variable>
                <name>mediaType</name>
                <node>//Dialog/mediaType</node>
                <type>CUSTOM</type>
            </Variable>
            <comparator>IS_EQUAL</comparator>
            <value>Voice</value>
        </Trigger>
        <Trigger>
            <Variable>
                <name>callType</name>
                <node>//Dialog/mediaProperties/callType</node>
                <type>CUSTOM</type>
            </Variable>
            <comparator>IS_IN_LIST</comparator>
            <value>ACD_IN,PREROUTE_ACD_IN,PREROUTE_DIRECT_AGENT,TRANSFER,OVERFLOW_IN,
                OTHER_IN</value>
        </Trigger>
        <Trigger>
            <Variable>
                <name>state</name>
                <node>//Dialog/participants/Participant/mediaAddress
                    [.='${extension}']/../state</node>
                <type>CUSTOM</type>
            </Variable>
            <comparator>IS_EQUAL</comparator>
            <value>ACTIVE</value>
        </Trigger>
    </triggers>
</TriggerSet>

 

 

Second Try - Custom Condition

After that I thought, maybe I can add an additional condition that checks against the callType variable, sure all answered calls would trigger the workflow's triggers, but the condition check could filter out those for outbound calls. Again I read some API docs and tried to update a workflow with condition set, at first I just tried a system variable for callType.

 

 

<Variable>
	<name>callType</name>
	<type>SYSTEM</type>
</Variable>

 

 

Success! - Custom Condition w/ Custom Variable Node

But that threw some errors in the API response about invalid name. I was about to throw in the towel, when I noticed the callType variable format that is used in the trigger variable element uses a custom variable with node, so I swapped out the system variable for a custom variable and it worked! After all both are just instances of SystemVariable. In my case, I had the node already from the trigger, but if you needed a system variable that wasn't available in the conditional dropdown but was available as a system variable you could find it with the SystemVariable - List endpoint.

Editing the workflow in the front end is a no-go however, if you modify any part of the workflow definition, it will update the condition to callVariable1 which is a downside. But the API call is dumb easy. The condition applies after the trigger so you can only ever be less permissive rather than more permissive with the conditions. 

twalker1223412342132_0-1699306173585.png

Rolling the custom workflow is as easy as creating it in the front-end, then grabbing the list from the Workflow - Get List endpoint. Once you find the correct workflow, put it into your text editor and add another condition to the condition set. You can read about the different call types for contact center express here. Then just use the Workflow - Update api making sure to pass in the id in the url and that you are passing in a single <Workflow> element and not a <Workflows> element.

 

 

<Condition>
	<Variable>
		<name>callType</name>
		<node>//Dialog/mediaProperties/callType</node>
		<type>CUSTOM</type>
	</Variable>
	<comparator>IS_IN_LIST</comparator>
	<value>ACD_IN,PREROUTE_ACD_IN,PREROUTE_DIRECT_AGENT,TRANSFER,OVERFLOW_IN,OTHER_IN</value>
</Condition>

 

 

 

 

 

0 Replies 0