talks about passing it in as attributes, but I need some guidance on the format. Snippet below is the Action object I created (${input.conversationId} is my input contract). Is what I have in bold the right way to pass Participant Data into the workflow?:
I had the same problem some weeks ago.
Unfortunately it is not possible to map the current attributes property with the current participant datas inside from the trigger event automatically on a input variable in the Architect Workflow. I tried different settings with no luck.
But you can use the "Get Conversation Data" block in the workflow. There you can read every participant data which is currently attached at the conversation. For "Conversation ID" in block you have to use the variable "Flow.conversationId". This is another "Input to flow" variable you have to create in the Workflow. The conversationId is a property which is add to every Process Automation event.
But the issue here is that in a workflow there is no Flow.conversationId (or State.conversationId. Essentially you don't get any "system" variables). It has to be passed in as an input parameter of the workflow.
yes you don't get the properties of the event (e.g. conversationId or participantId) automatically.
For every property you need you have to create a input variable in the workflow. Unfortunately this is not working for properties of type JSON object...
"When a workflow is executed, all the top-level primitive attributes of the event payload are available for a user as input variables to the flow."
I'd be curious which event topic you're using that does not contain conversationId as a top level primitive, making it unavailable as an input to your workflow?
In every trigger event the properties of the common dimensions are always included (e.g. the conversationId).
So you have of course the conversationId which you need to get the participant data you need for further processing in the workflow. But you always need the "Get conversation data" block in your workflow.
I feel like we're talking past each other, here. So let me reset:
I understand that event properties is not inherently available within a workflow. The properties must be passed in to the workflow as input parameters
I also do not have any issue that I have to pass it in. I actually do not see this as a limitation or a defect
What I am not able to figure out is how to pass the properties into the workflow from a trigger topic. None of the examples I found online gave me any guidance of how to pass it in as input parameters.
The name must match with the name on the page above and it must be marked as Input variable.
And I think this is only working with variable type String.
So with this you can have access to that variable within your workflow which means access to the same values as in the event which triggered the workflow.
OK, screenshot below shows an Action object that has the /api/v2/processautomation/triggers as the request URL. In the request body, I have specified I want the trigger to happen on the customer end event:
"topicName": "v2.detail.events.conversation.{id}.customer.end",
The target of this action is to invoke the workflow:
"target": {
"type": "Workflow",
"id": "0a8d70dd-acd3-4e06-b764-4057200664ca",
How should I craft the request body if I want to (as example) pass the conversationId of this call as the input to the workflow I'm invoking?
The passing of the variable data is not part of the trigger config. As long as you do the steps outlined above by Christian, the data will magically pass into the flow based on the Flow.XX variable matching an attribute from the event schema.
IE create the variable 'flow.conversationId' with the option 'input to flow' on your workflow, and via magic that ID will pass into the flow from the trigger because of the name match and input to flow flag.
Ah! Thanks Brad for translating what Christian has been saying all along. "Magic" was the keyword here! My too logical mind just could not make the jump that a data could be received without being explicitly passed in.
Christian, I apologize for not picking up what you're laying down.