Email Workflow

This article provides an overview of the available node types, generic properties of email workflows, and introduces the new designer toolbar, among other topics.

Email workflows can be found by navigating to Email > Workflows using the Graia CCaaS Portal.

Tip

New to email workflows? Follow Build your first email workflow, a 20-minute step-by-step tutorial.

Workflow generic properties

Workflow Name

The workflow name is a required parameter, as it serves as a selection identifier for a specific channel. See the naming best practices.

Idle timeout

Idle timeout, by default, is set to 1440 minutes (24 hours). If there is no activity for the specified time, the system will automatically close down the conversation.

For example, if the workflow idle timeout is set to 10 minutes and the agent or the customer does not send any messages, the system will automatically close the conversation after the 10 minutes have passed.

The maximum value for the idle timeout parameter is 30240 (21 days). The minimum value is 10 minutes.

When creating a workflow, mind the idle timeout!

Workflow designer

After you've provided the generic properties for a workflow and clicked "Create," you enter the workflow designer. This is where you build and customize your workflow to meet your specific needs.

Node types

Jump to a node:

Start and end

Node What it does
Start Here node The starting point of every workflow.
End conversation Ends the workflow.

Reply and wait

Node What it does
Send reply Sends an automatic reply using an email template.
Forward Forwards the email to another address.
Wait for customer reply Pauses the workflow for a set time, for example to send reminders.

Route the email

Node What it does
Check opening hours Routes based on the channel's opening hours.
Check queue state Checks a queue before sending the email to it.
Queue Puts the email in a queue for agents.
Customer intent evaluator Routes based on the email's subject line, content or both.
Switch Routes based on conditions on conversation, customer or other data.
Sampling Sends a set percentage of emails down a different path.

AI and language

Node What it does
Conversational bot Lets an AI bot handle the email.
Categorizer Applies a category from a categorization rule, after a Conversational bot.
Detect customer language Detects the language of the customer's last email.
Set customer language Sets the customer's language for translation and other language services.

Data and integrations

Node What it does
Extract data Pulls values out of the subject or body using regular expressions.
Set data Stores workflow data for use later in the workflow.
JavaScript Runs your own JavaScript code.
Custom integration Hands the conversation over to a third-party system.

Start Here node

The "Start Here" node is the default starting point in your workflow. It serves as the initial step from which your workflow begins. To use this node, click on the black dot and drag it in any direction to open a context menu. From this menu, you can choose other available nodes to build and customize your workflow.

Categorizer

Use this node after a Conversational Bot, to apply one of the categories in the linked categorization rule. Alternatively, apply categories manually.

  • Categorization rule: select a categorization rule created in your tenant. Graia CCaaS will attempt to match one of its categories to the initial message.

  • Manual categorization: set this toggle to be able to select a Main and a Secondary category from the selected categorization rule in case your flow needs specific categories applied.

    Note that for manual categorization, you can only have a single categorization node on any given flow branch.

Outputs:

  • Success: One of the category-subcategory pairs was associated to the conversation.
  • Uncategorized: For automatic categorization, in case the system failed to match any category in the linked categorization rule.

The node also creates the following workflow properties, that can then be used for example in the Switch node for routing decisions:

  • MainCategory: contains the main category value as the node selected.
  • SubCategory: contains the sub-category value the node selected.

Check opening hours

This node is responsible for verifying your Channel's opening hours and enables you to make routing decisions based on the verification results. The available outputs are as follows:

  • Open: The Channel is currently within business hours and not on any holidays.
  • Closed: The channel is currently outside of business hours and not on any holidays.
  • Holiday: The channel is closed due to a set holiday.

Feel free to customize the name of the "Check opening hours" node to suit your needs.

Check queue state

The Check Queue State node allows administrators to pre-check a queue and perform routing decisions as it has similar outputs as the queue. The benefit is that the customer does not have to navigate through the entire complex flow, but instead can be routed elsewhere based on the result of the check.

  • Input: Queue to check. Select the queue you wish to check.

  • Outputs:

    • Size Limit Reached. This can be used if the queue has a Max queue size set.
    • EWT limit reached. This can be used if the queue has an EWT limit set.
    • No agent logged in. This can be used if the queue has the No Agent logged in output set.
    • No staffed agent logged in. This can be used if the queue has the No Staffed Agent logged in output set.
    • No available staffed agent. This can be used if the queue has the No available staffed agent output set.
    • Pass. The conditions for the outputs were not met or the outputs were not set, as such, passing through.

Conversational bot

Use this node to engage your customer with a subject matter expert AI-based conversational bot.

Carefully type the Instructions for the bot. Instructions help it understand its role, responsibilities and tone.

Note

Please carefully read and follow the bot instruction guidelines. This is critical for proper bot operation.

Optionally use one or more preconfigured external custom service integration APIs that can offer additional insight, deliver precise information, or execute external tasks. Select them from the Integrations dropdown. You can select any number of preconfigured integrations, the bot will consider all.

Associate an available Knowledge base to the bot. This can dramatically enhance the relevance and contextual quality of its responses.

Results in AI technology are not absolute, every outcome has a confidence level associated internally. Because it is inconvenient and time consuming to sort out misunderstandings in an email exchange, you can designate at what Knowledge base confidence threshold you consider the outcome of the KB result to be low enough for the node to be considered failing. You can then remedy this in other parts of the flow by sending the conversation to human queue, or to another, maybe more relevant bot, etc.

Select an appropriately created Email template for the bot to use in its response back to the customer. The template can contain any data replacement fields (e.g. to add customer details) but must contain the #BotResponse field so the bot response is inserted to the response email.

Use the Enable draft mode toggle to avoid sending the response from the bot back to the customer directly. Instead, connect the relevant Email draft created output to an agent queue for human revision and dispatching. Use this feature to assess the quality of your overall bot setup, the instruction prompts, your linked KBs and any integrations. When satisfied with the quality and reliability of the bot responses, change this to the normal operational mode (disable the toggle) for the bot response messages to be sent directly to your customers.

The node will use the language in the email template matching the customer email (in case a Detect Customer Language node was used earlier) or the one marked as fallback.

Advanced configuration:

  • Temperature: use this to control consistency and predictability of the texts the bot generates. A value of zero provides maximum consistency, while a value of 1+ provides maximum creativity and randomness. On a general level, keep it lower and test any increase extensively.

  • Max output token count: a circuit breaker to control the maximum amount of text generated by the bot. Setting it too low will abruptly cut the result text. Test any change extensively.

  • Customer history control: A slider to determine how many past messages will be used by the bot as a context window. Set this to a lower value to ensure the bot remains focused on the current questions and discards context from X messages ago, or set this to a higher value to increase the context window and ensure the bot remembers X messages. Please note that a higher context window may increase your consumption cost.

  • History mode: Determine whether the bot should use only the current email conversation as a history or the entire email thread.

  • Attachment handling: controls if, and how the bot considers attachments added to the conversation.

    • None: the bot won't process any attachments in the conversation in its operation.

    • Bot: the bot will attempt to process any supported image file attached to the conversation. Note, that it does not process other file types and it processes the attachment of the last customer message only.

    • External system: an external system will process the attachment, sending its result back to the bot. This external system must conform with our attachment external handling API workload, authentication, error handling, etc. This requires additional settings to specify:

      • Attachment processing URL: the URL to send the attachment to for processing.

      • Attachment processing API Key: the API Key the bot will authenticate itself with at the external system (see our Developers Guide link above for details).

  • Fresh start: Allows the bot to start as if there are no messages in the history before reaching this node. This is useful in multi-bot scenarios with different controls in terms of the history. Outputs:

  • Email sent: the bot considered its response to the customer message and the result of the optional knowledge base lookup to be high enough in confidence that it actually responded.

  • Email draft created: instead of sending the bot's response back to the customer directly, use this to route the conversation into a queue node for human agent revision.

  • Low confidence: The confidence level of the selected knowledge base query result was lower than the set threshold.

  • Failed: The bot could not comprehend or answer the customer request, or lower level technical problems were encountered with the AI model.

  • Optionally define additional outputs by supplying further AI instruction prompts for various business topics this node is not the expert of.

    • Use them to list the various business topics this node is not the expert of. Having multiple different conversational bots each being an expert on different business topics and jumping between them as the customers' requirements change can greatly expand the flexibility of your workflows and the customer experience.
    • Each output needs a unique and short Name so their label on the node can be distinguished, and a Description. All common AI prompt engineering principles you used when crafting the Instruction field apply here too.
    • You may require the bot to collect data from the customer before calling an output, you may configure this in the Data collection drop-down of an output. You must provide a name for the variable, a description so that the bot understands what the variable is for, required flag and the type, which can be text, boolean, choice or number. The bot will attempt to extract all relevant data from the conversation, but please note that the decision lies with the LLM.
    • Outputs are evaluated in the order they are configured, meaning that if both option 2 and option 3 match, the bot exits through option 2, the one higher in the list.

Custom integration

This node is an exit point from the workflow to a 3rd party solution supporting a custom integration. It requires a URL and an API Key.

Customer intent evaluator

Use this node to make routing decisions in emails based on their subject line, content, or both. Graia CCaaS scans the subject and content of the email and considers it a match if it contains the specified keyword.

Key points for using this node:

  • Keywords in Groups: Keywords are organized into groups, and these groups represent the outputs of the node. You can specify multiple keywords within a single group, but you're limited to up to 10 groups and 50 keywords.

  • CSV Template: You have the option to download a pre-formatted CSV template where you can enter your keywords and assign them to specific groups.

  • Exact Match Requirement: When scanning the content or subject of the email, the keyword or phrase must be an exact match. For example, if your keyword is "windows 11 upgrade," it will not match "upgrade to windows 11."

  • Multiple Matches: If multiple groups are matched within the content, Graia CCaaS will use the first match as the output. To fine-tune your workflows, you can create multiple evaluator nodes.

  • Subject and Content Matching: When both subject and content options are used together with a single CSV, the subject is evaluated first.

  • CSV Format Rules: The CSV format must not contain question marks, signs, brackets, or any other punctuation. Empty keyword groups or key phrases are not allowed. Repeating the same key phrase within a group or assigning the same key phrase to two different groups is also prohibited.

  • Validation: While the node allows you to upload CSV files, it won't allow you to save them if they are invalid. This ensures that any errors in the CSV can be visually corrected, and error messages are provided when an invalid CSV is uploaded.

By utilizing this node effectively, you can route emails based on specific keywords or phrases found in their subject or content.

Warning

We recommend using Notepad++ to handle the CSV file if you plan on using special characters as Excel does not save the Unicode characters.

Detect customer language

The Detect Customer Language node automatically detects the language of a customer based on the last received customer email message and stores the detected language in a workflow variable. The node detects the language based on the textual content of the email body. If the email contains words from multiple languages, the predominant language is selected.

The detected language can be used together with a Switch node to route workflows by language (e.g. Romanian, English, Hungarian).

Nodes supporting the multi-lingual email templates will use the detected language to generate a reply to the customer, if the template correctly supports the detected language, otherwise, the fallback template language is used.

This node has a single output called Then.

End conversation

Use this node to wrap up and conclude your workflow. When an email conversation reaches this point, the conversation is closed.

Extract data

The Extract Data node evaluates the subject, body, or both of an incoming email using configurable regular expression (regex) rules and stores extracted values into workflow variables.

This node enables workflows to automatically capture structured data (e.g. contract IDs, order numbers, references) from unstructured email content.

Matching & Storage Logic:

  • Single Match: If a rule matches once, the extracted value is stored in the specified workflow variable.
  • Multiple Rules: Multiple rules can match during a single execution. Each matched rule stores its result in its own corresponding workflow variable.
  • Multi-Match (Same Rule): If Allow multi-match is enabled and multiple matches are found for the same rule all extracted values are collected, duplicate values are filtered out, remaining unique values are joined using the configured separator, the final concatenated string is stored in the workflow variable.

Outputs:

  • Match: Triggered when at least one rule successfully extracts and stores a value.
  • No match: Triggered when no rules extract or store any value.

Forward

Forwards the email to the Destination email address, with the channel's own mailbox as the sender. You may include a template that will be appended as the forward message. Attachments from the forwarded email or the template will be included. Variable placeholders will be replaced with their actual values, if available and it will match the language, if correctly defined in the workflow and template, otherwise, fallback language of the template will be used.

Output:

  • Then: Hook any followup nodes here to process the original inbound email further.

JavaScript

The JavaScript node allows integrators to write JavaScript code directly into the portal using a capable editor. This allows integrators to use the node instead of creating a middleware or Azure Function for simpler operations. The node supports executing JavaScript, it can send HTTP requests, supports reading & writing workflow variables and basic conversation data.

The node properties:

  • A description for the node, use this to explain to other integrators what this node is for.
  • Success output, this is used when the code inside the node is successful and the conversation continues through this path.
  • Failed output, this is used when the code fails for any reason and the conversation goes through this path.
  • Copy Code button, this allows integrators to quickly copy the code inside the node to paste it elsewhere.
  • Edit code, this opens the code editor and allows for writing the code itself and testing it.

The code editor is based on the Monaco Editor, also powering VSCode. The system passes data to the node, meaning in the code, you can access the following data:

  • conversation.id - this is the unique ID of the conversation
  • conversation.customerId - this is the unique ID of the customer that is part of the conversation
  • conversation.customerIdentifier - this is the email address or phone number (depending on the media type) used to identify the customer.
  • workflowVariables.{yourVar} - workflow variables configured elsewhere in the workflow.

For testing purposes, you may provide environment data (conversation ID, customer ID, customer identifier) as well as key-value pairs workflow data to be able to test your code without having to initiate a conversation. Simply click Execute Code to test your code, the console will display any information coming from the code as well as the output variables that you can define in your code using the syntax such as workflowVariables.myVar = 'asdf'

Please note that the data provided as environment data as well as the test workflow variables are discarded when leaving the editor, regardless if the code or workflow was saved or not. Be mindful of the execution timeout set by the system.

Send reply

The Send Reply Node empowers workflow designers to utilize pre-configured email templates for sending automated replies to customers. For instance, if an email is received outside of business hours, an automated response can be dispatched to inform the customer about the operational hours and subsequently route the conversation to a queue.

The node utilizes the appropriate language variant from the linked template, or uses the one designated as fallback.

  • Template Requirement: To use the Send Reply Node, you must have an email template configured. You can refer to the Email Templates section for detailed information on setting up these templates.

  • Handling New Conversations: An auto-reply is dispatched for each new conversation. This means that if a customer's email is currently being handled by an agent, additional emails from the same customer with the same subject (follow-ups) will not initiate a new conversation. In this scenario, no auto-reply will be sent. However, if the agent concludes the conversation, subsequent email replies from the customer will trigger the Send Reply Node as the conversation re-enters the workflow.

By leveraging the Send Reply Node and email templates effectively, you can provide automated responses to customers based on specific criteria, enhancing your email handling processes.

Output:

  • Then: Hook up the next node, for example a Queue.

Queue

Used to load the conversation into a queue of agents. The Queue node is the queue itself: you give the queue its name and set its routing mode in the node.

Routing mode

When creating a queue, you must choose a routing mechanism: automatic or manual. This choice cannot be changed later for a given queue, but you can delete the queue and recreate it with a different routing mechanism.

  • Automatic Queue: The system uses intelligent routing to find the first available skilled agent.
  • Manual Queue: Skilled agents can manually pick items from the queue. Agents assigned to manual queues can view all items in their team's queue, including items in manual queues, in their agent performance dashboard.
  • Hybrid Queue: The system mixes automatic and manual, allowing the system to use intelligent routing to find the first available skilled agents, but also allowing skilled agents to manually pick items from the queue.

Queue parameters

  • Emergency: When activated, this feature ensures that conversations arriving into this queue are prioritized over others if the agents assigned to it are also in demand by other queues, as long as those other queues aren't marked as "emergency" as well. If multiple queues are set to "emergency" within the same tenant and share the same agents, conversations in these queues will be treated equally, following a first-come, first-served agent routing policy.
  • Max Queue Size: Set the maximum number of parallel conversations allowed in the queue.
  • Route to customer's preferred agent: When enabled, Graia CCaaS attempts to route the conversation in the queue to the agent who is marked to be the preferred one for this customer.
  • Preferred agent timeout: The amount of time Graia CCaaS will wait for the preferred agent if they happen to be unavailable.
  • SLA Threshold Time: Enable SLA (Service Level Agreement) for the queue. If SLA-based routing is enabled, this information will be used to determine the priority of the conversations.
  • Estimated Wait Time Limit: Specify the MAX estimated wait time. Once the estimated wait time limit is breached, further conversations will no longer be queued, the Estimated Wait Time Limit Reached output will be used instead.
  • Agent Workspace: Choose an agent workspace for this queue. Learn more about agent workspaces.
  • Attribute Requirements: Specify the required skill attribute and its value to route conversations from this queue to agents.

Outputs

  • AgentDisconnect: Define next actions for when the agent closes the task, such as survey questions.
  • Size Limit Reached: Define actions for when the maximum queue size is reached.
  • No Agent Logged In: Define actions for when no agents are logged in across the tenant.
  • No Staffed Agent Logged In: Check if there are agents with proper attribute assignment as well as workitem thresholds logged in to handle conversations from this queue, if not, define next action.
  • No available staffed agent: Check if the staffed agents for this queue are also available, if not, define next action.
  • Estimated Wait Time Limit Reached: Define actions for when the estimated wait time limit set on the queue is reached.

Queue entry logic

Before a conversation enters the queue, the following checks are performed to reveal whether it needs to be bypassed altogether. These checks are associated to specific outputs, and are executed in this order:

  1. No Agent Logged In: Check if any agents are logged in across the tenant. If yes, proceed to the next check; otherwise, use this output.
  2. No Staffed Agent Logged In: Check if the logged-in agents are skilled and have the appropriate work-item thresholds. If yes, proceed to the next check; if not, use this output.
  3. No Available Staffed Agent Logged in: Check if the staffed agents are also available, if yes, proceed to the next check, if not, use this output.
  4. Max Queue Size: Check if the conversation would exceed the specified limit. If yes, use this output; if not, proceed to the next check.
  5. Estimated Wait Time Limit: Check if the current wait time is higher than the specified limit, if yes, use the output flow; if not, then the conversation enters the queue.

Set data

Set Data node allows you to set workflow data and re-use it later, for example in a Switch node. Useful for future integrations.

Set customer language

This node specifies the customer language and the associated language providers for the various language services. For email, specifically, this is useful to enable the Email translation feature.

Select a Customer language profile from the list. The node displays the features the selected profile offers.

Note

In case the Email translation feature is not enabled in the selected profile, but the flow actually routes the email conversation to an agent who does not know the customer's language, then there will be a language discrepancy and the conversation will likely fail.

Outputs:

  • Then: A generic output, use it to hook up the next node.

Feature support:

  • Email Translation: Will set the language, the translation engine and the email translation feature for the current path, enabling email translation between the agent and the customer if the languages set for the agent in their profile configuration do not match the language from the set customer language node.

Please note that if multiple set customer language nodes with the same or similar functionalities exist on a given workflow path, the last node encountered by the customer will be taken into consideration.

Switch

The Switch node enables workflow designers to assess specific properties or fields of various categories of data (e.g. conversation or customer details, etc.), establish conditions for them and make routing decisions based on the result of these.

Upon creating the node, you first designate which categories of data it will offer properties from. This can be set only once and will not be changeable later on for the given node.

The available data sources to load properties from:

Data source Description
Workflow data Data fields set through the Set Data node, via custom integrations, conversational bots.
Customer details Customer record properties in case the customer of the conversation is identified by the time this node gets activated.
Customer language In case the flow handles conversations in different languages.
Calendar events Events scheduled in the tenant calendar.

You can define up to 9 workflow conditions, and each condition will have its corresponding output. Additionally, there is a default output option provided.

This node can be effectively paired with the Set Data node, and you also have the option to utilize custom fields defined per tenant or business unit.

  • Outputs:

    • Each condition property has its own output, allowing you to determine the course of action based on these properties.
    • Default: Serves as a failsafe, specifying what should happen if no condition is met.

Sampling

The Sampling node offers chance-based flow management. You set the sampling percentage and the node "throws the dice" at every conversation to activate its Sampled or Not Sampled outputs based on whether the current conversation hits the set probability or not. This can be used to engage branches of the workflow in a probabilistic manner, for example to offer customer surveys for a portion of the total number of conversations, etc.

Note that the probability is not measured and applied on a defined time scale, the node calculates it in a fully random fashion at every conversation. Therefore Graia CCaaS does not guarantee that the set ratio will be honoured in any particular time frame. It is expected to honour it in general, on large enough number of conversations.

Outputs:

  • Sampled - The conversation falls within the designated sampling rate.
  • Not Sampled - The conversation is not marked for sampling, it falls outside of the designated ratio.

Wait for customer reply

This node pauses the email workflow for a set wait period, letting you act on expiration for example to send reminders. Incoming replies during the wait can trigger other nodes.

  • Wait timeout: specify the wait time in Days, Hours, Minutes and Seconds with a maximum of 20 days.

Outputs:

  • Reply received: hook up nodes to handle a reply before the timeout expires.
  • Timeout: use this to deal with the expiration of the specified wait time. E.g. send a reminder email message and add another wait node, etc.

Using the workflow designer

Workflow containers, the designer toolbar, saving, cloning workflows and nodes, multi-select, deep links to nodes and node search work the same way in voice, chat and email workflows. See Using the workflow designer.

Edit workflow generic properties

For existing workflows, you may edit their generic properties by clicking a workflow in the list, then using the pen icon on the top left corner of the screen. A modal window, commonly known as a popup, will be shown. Modify your workflow's name or idle timeout, then click OK. Please note that the OK button is not a replacement for Save. You will need to save your workflow by using the dedicated icon located at the top left corner afterward.