Overview

Agent Triggers connect an application element to an AppNavi Agent. When a user interacts with the configured element, AppNavi can offer to start the associated Agent and run its configured workflow.

For example, you could configure a trigger on an application button so users can start an Agent that helps them complete a business process. The Agent determines what happens next based on its configured actions and logic.

Agent Triggers are managed through the Knowly experience in the AppNavi Avatar and the Manage Knowly Contents area in the Portal. You can configure how the trigger responds to user interaction, choose the Agent to run, and restrict availability using a target audience.

Use this guide to create, configure, test, and publish an Agent Trigger.

Who should use this guide?

This guide is intended for:

Content authors: Create Agent Triggers and capture the application elements that activate them.
Tenant Owners: Manage triggers in the Portal, assign target audiences, and publish triggers.
Application administrators: Help verify that the trigger works correctly in the target application.

Before you start

Make sure you have:

Access to the AppNavi Avatar and the Knowly area.
An existing Agent that is ready to be triggered.
Access to the target application and the element where the trigger should appear.
The appropriate permissions to create or manage Agent Triggers.
A clear understanding of which users should be able to use the trigger.

Recommended: Test the Agent independently before connecting it to an application element. Confirm that its workflow and expected actions work as intended.

If the Agent has not been created yet, start with Agents.

How Agent Triggers work

An Agent Trigger connects three things:

Application element: The element the user interacts with, such as a button, link, or field.
Trigger configuration: The settings that determine how the element is captured and how it behaves when activated.
Agent: The configured workflow that runs when the user starts the Agent.

You can also assign a target audience so that the trigger is available only to users who meet the defined conditions.

Step 1: Create an Agent Trigger

Open the AppNavi Avatar.
Navigate to Knowly.
Open the Agent Triggers section.
Open the context menu and select Add Agent Trigger.
Enter a descriptive title and description.

Choose a title that helps authors and administrators understand the trigger's purpose. For example, Start Expense Review is more useful than Trigger 1.

Expected result: The Agent Trigger configuration dialog opens with the title and description entered.

Step 2: Choose the Agent

Locate the Agent setting.
Select the Agent that should run when the trigger is activated.
Confirm that the selected Agent contains the intended workflow.

The trigger starts the configured Agent; it does not define the Agent's workflow itself.

Expected result: The trigger is associated with the intended Agent.

Step 3: Capture the application element

Capture the element where users should activate the Agent.

Open the trigger's element-capture controls.
Navigate to the relevant application element.
Capture the element that should activate the trigger.
Review the capture to confirm that it identifies the intended element.

If the Agent requires information from the application, ensure that the relevant elements are captured so the Agent can use the extracted data where its workflow requires it.

Expected result: The trigger is connected to the intended application element.

Configure the capture settings

The trigger dialog includes the following options:

Setting	What it does	When to use it
Send RAW HTML	Captures the selected element's full raw HTML instead of processed or cleaned content.	Enable it when the Agent's use case requires the raw HTML of the selected element. Consider what page content may be included before enabling it.
Auto Tracking	Enhances the search mechanism used to locate the captured element.	Consider enabling it when the element needs more robust identification. Test the result in the target application.
Source	Determines whether the source is `same` or `other`. `Same` uses one capture; `other` uses two captures.	Choose the option that matches the source and capture arrangement required by your trigger.

The documentation does not specify all technical conditions for choosing same versus other. If your use case requires two distinct captures, verify the intended source arrangement in the editor before publishing.

Step 4: Configure interaction behavior

Interaction Behavior controls whether the original application element can be clicked while the trigger activates or the Agent runs.

Choose the option that fits the action and the expected user experience.

Option	Behavior	Example consideration
No Blocking	The element remains clickable when the trigger is activated.	Consider this when the application's normal click behavior should remain available.
Block First Click	The element is not clickable on the first click when the Agent Trigger is activated.	Consider this when the first click should start the Agent rather than perform the element's normal action.
Block Until Agent Completes	The element remains unclickable until the Agent Trigger's execution completes.	Consider this when users should not repeat the action while the Agent is running.

Important: These settings affect the user's interaction with the application. Test the selected behavior carefully if the element submits information, changes records, or starts another process.

Expected result: The trigger follows the selected interaction behavior during testing.

Step 5: Save and test the trigger

Before assigning the trigger to a wider audience, test it in the target application.

Save the Agent Trigger using the available controls.
Open the application where the element was captured.
Navigate to the relevant page and locate the captured element.
Activate the element.
When the confirmation prompt appears, select No.
Confirm that the Agent Mode session does not start.
Activate the trigger again and select Yes.
Confirm that AppNavi switches from the default Knowly chat interface to the Agent Mode interface.
Verify that the configured Agent begins its workflow.
If needed, use Stop Agent Mode to terminate the session.
If the Agent completes successfully, confirm that the button changes to Agent Completed.

Expected result: The trigger activates the intended Agent, the confirmation choices work as expected, and the Agent Mode session follows the configured workflow.

Only one Agent Mode session is allowed at a time. External Agent Triggers remain disabled while an Agent Mode session is active so they do not interfere with the current workflow.

Step 6: Manage the trigger in the Portal

After creating a trigger in the Avatar, you can manage it from the Portal.

Open the AppNavi Portal.
Navigate to Manage Knowly Contents.
Open Agent Triggers.
Locate the trigger you created.
Open it for editing to review its configuration and target audience.

Tenant Owners can select the relevant target audience and save changes using Save Changes in the upper-right corner. Multiple triggers can also be selected and published together using the multi-select control.

Expected result: The trigger is available for management in the Portal, and authorized administrators can configure its audience and publication settings.

Step 7: Configure the target audience

A target audience controls which users should receive the Agent Trigger. This helps ensure that a trigger intended for one department, user group, or application context is not shown indiscriminately to everyone.

For example, an organization might configure an expense-review trigger for Finance users rather than making it available to all employees. This is an illustrative use case; the actual result depends on the target audience rules and the values available for evaluation.

To configure the audience:

Open Manage Knowly Contents → Agent Triggers.
Select the trigger you want to edit.
Open its target audience settings.
Select the required target audience from the available options.
Save the changes.
Publish the trigger using the available publishing controls.

If the required audience does not exist, create it first using the Target Audience guide.

How the target audience affects trigger behavior

Users who match the configured audience conditions can receive the trigger.
Users who do not match those conditions should not receive the trigger.
A trigger may be correctly configured but unavailable to a user because the user's values do not satisfy the audience rules.
Publishing the trigger and configuring its audience are both important when making it available to the intended users.

Expected result: The trigger is published with the intended audience configuration.

Step 8: Verify target audience behavior

Test both an intended user and a user who should not qualify, where your test environment permits it.

Confirm the audience rules and the values they evaluate, such as labels, country, query parameters, or Identity Provider claims.
Use the Portal's target audience simulation feature where appropriate.
Test the trigger with a user or test profile that should match the audience.
Confirm that the trigger is available and can start the Agent.
Test with a user or profile that should not match the audience.
Confirm that the trigger is not available to that user.
If results differ from expectations, review the audience rules, user values, and publication settings.

A successful audience simulation is useful for checking the rules, but you should also verify the actual trigger in the target application.

See Target Audience for rule configuration and simulation instructions.

Example use cases

These examples illustrate how you might use Agent Triggers. The exact workflow depends on the Agent you configure.

Example 1: Start an expense review

Goal: Let Finance users start an Agent from an expense-related application element.

Capture the element that should launch the review workflow.
Select the expense-review Agent.
Choose the interaction behavior that avoids unintended duplicate actions.
Assign a target audience for the intended Finance users.
Test with a matching user and a non-matching user.

Success looks like: The intended user can start the expense-review Agent from the configured element, while users outside the audience cannot access the trigger.

Example 2: Collect information from an application page

Goal: Start an Agent that uses information from a selected application element.

Capture the trigger element.
Capture the relevant data elements required by the Agent.
Enable Send RAW HTML only if the Agent's use case requires the raw HTML.
Run the trigger and confirm that the Agent can use the information it needs.

Success looks like: The Agent runs its configured workflow using the expected information from the captured elements.

Example 3: Prevent repeated clicks while an Agent runs

Goal: Reduce the risk of users starting the same application action repeatedly while an Agent is executing.

Capture the relevant application element.
Select the Agent.
Set Interaction Behavior to Block Until Agent Completes.
Test the behavior while the Agent is running and after it finishes.

Success looks like: The element remains unclickable during the configured execution period and becomes available again when the Agent Trigger completes, as expected.

Troubleshooting

Problem	What to check	Recommended action
The trigger does not activate	Confirm that the correct element was captured and that the trigger is saved.	Reopen the trigger configuration, verify the capture, and test again.
The wrong element activates the trigger	The captured element may not uniquely identify the intended target.	Recapture the correct element and test it in the target application.
The Agent does not run as expected	Confirm that the intended Agent is selected and that its workflow is configured correctly.	Test the Agent independently, then test it through the trigger.
The application element remains clickable unexpectedly	Review the selected Interaction Behavior option.	Select and test the behavior that matches your requirements.
A user cannot see the trigger	Check the target audience, the user's values, and the trigger's publication status.	Simulate the audience and test with a matching user.
The trigger appears for the wrong users	Review the target audience rules and values used to evaluate them.	Correct the audience configuration, save, publish, and retest.
Another trigger does not work during Agent Mode	Only one Agent Mode session is allowed, and external Agent Triggers remain disabled while it is active.	Finish or stop the active session before testing another trigger.
The Agent does not receive the expected page data	Review which elements have been captured and whether the Agent requires raw HTML or extracted element data.	Update the captures and retest the Agent workflow.

Knowly Actions

Knowly actions define how agents respond when triggered during a user interaction. They form the behavioral logic of the guidance system, instructing agents on what to do, how to respond to user input, and what information to provide. Actions are the bridge between agents (the "who") and triggers (the "when"), determining the "what" and "how" of the guidance experience.

Understanding Knowly Actions in Context

• Knowly Actions work as part of an integrated system:

Component	Role
Agents	The intelligent entity that performs actions in response to user needs
Triggers	The events or conditions that activate an agent
Actions	The specific behaviors and responses executed by the agent when triggered

What Are Knowly Actions?

A Knowly action is a discrete unit of behavior that encapsulates:
• The specific task or goal the agent should accomplish
• How the agent should respond to user input and questions
• What information or assistance to retrieve and provide
• How to guide the user through a conversation toward resolution
• The validation rules to ensure data accuracy and completeness
• The conversation flow and prompts to present to users
• Each action is independent and discrete, allowing for modular, reusable agent behaviors.

Accessing Knowly Actions in the Portal

Knowly actions are managed through the Manage Knowly Contents interface. To access this:

In the Guidance module, click on the application settings menu.
Select "Manage Contents" from the dropdown options.
Click on "Manage Knowly Contents".

Application Settings Menu - Access "Manage Knowly Contents"

Managing Knowly Actions

The "Manage Knowly Contents" page provides a centralized interface for viewing and managing all Knowly actions. The Knowly Actions tab displays a table of all configured actions with their IDs, titles, and assigned agents.

Manage Knowly Contents - KNOWLY ACTIONS Tab - Displays all configured Knowly actions

Creating a New Knowly Action

To create a new Knowly action, click the "Add" button on the Knowly Actions tab. This opens the "Add new Knowly Action" dialog where you configure all parameters for the action.

Configuration Fields

Field	Purpose & Guidelines
Title	A descriptive name for the action that clearly identifies its purpose. Examples: "Weather Update", "Book Flight", "Technical Support". Keep titles concise and action-oriented.
Assigned Agent	Select the specific agent to which this action is assigned. Each action must be tied to one agent. The selected agent will execute this action when triggered.
Intent	A high-level description of what this agent is authorized to do. This should explain the action's purpose from a user perspective. Example: "Book a flight" or "Technical Support". This guides the agent's behavior and sets user expectations.
Prompt	Specific instructions telling the agent how to interact with the user and what information to collect. This is the core instruction set. Example: "Politely ask for the user's full name". Be explicit and unambiguous.
Validate Prompt	Rules for the LLM to check the accuracy and completeness of data received before proceeding. Example: "Ensure the output contains both a first_name and last_name field". These validation rules ensure data quality.

Add New Knowly Action Dialog - Configuration form showing all required fields

Editing Existing Knowly Actions

To modify an existing action, select it from the table and click the edit option. The "Edit Knowly Action" dialog opens with the current configuration pre-populated. You can update any field and save changes. The example below shows a "Weather Update" action with example values filled in.

Edit Knowly Action Dialog - Example of "Weather Update" action

Knowly Action Behavior in Practice

On the Portal (Knowly Interface)

When an action is triggered in the portal, the user sees the Knowly chat interface with the agent executing the action according to its configuration.

Portal Knowly Interface

Agent Mode Interaction

When the agent is in Agent Mode, it actively collects information from the user and validates input according to the validation rules defined in the action.

Agent Mode - Weather Details Retrieval

Example Workflows

Example 1: Weather Information Action

Trigger: User asks "What's the weather like?" or "I need weather information"
Action Activation: Weather Update action is triggered
Intent: Provide current weather information for the user's location
Initial Prompt: Agent asks: "Which location would you like weather information for?"
User Input: User responds: "Frankfurt, Germany"
Validation: Validate Prompt checks that location is provided and in correct format
Data Retrieval: Agent fetches weather data for Frankfurt, Germany
Response: Agent displays detailed weather information (temperature, wind, humidity, etc.)
Completion: User can request another location or exit the action

Agent Triggers & Knowly Actions