The Conversion Mode Feature

Configure a connection with Conversation Mode

Conversation Mode lets you configure a connection by describing the required synchronization behavior in natural language. Aida captures your requirements and continuously generates the underlying Exalate scripts.

Aida is the name used for Exalate’s AI-driven capabilities supporting connection setup, configuration, testing, and troubleshooting.

Choose Conversation Mode when you prefer to define the integration through a guided conversation rather than writing Groovy scripts directly.

Lab feature

Conversation Mode is publicly available but remains under active development. Review and test the generated configuration before publishing it.

Conversation Mode or Script Mode

Both modes create the same type of Exalate synchronization configuration.

You can switch a Conversation Mode connection to Script Mode. Currently, this switch is permanent and the connection cannot be switched back.

This is a temporary limitation. Exalate is developing a hybrid configuration experience in which conversation and direct scripting can be used together.

How Conversation Mode works

The configuration process follows a repeating cycle:

Describe → Clarify → Generate → Test → Refine → Publish

1. Describe how items should be synchronized.
2. Answer Aida’s clarification questions.
3. Aida captures the requirements and generates the scripts.
4. Test the current draft.
5. Correct or extend the requirements through the conversation.
6. Publish the configuration when it is ready.
   
   

The conversation is the main way to manage the requirements. The generated Groovy scripts remain the executable configuration underneath.

Configure one direction at a time

Each conversation applies to one direction of the connection.

For example, while configuring ServiceNow → Jira you can describe:

• what ServiceNow sends

• how Jira applies the received data;

• what Jira item should be created or updated.

To configure updates in the opposite direction, switch the connection direction and start a separate conversation:

Jira → ServiceNow

When you provide a requirement that belongs to the opposite direction, Aida points this out but does not capture it in the current conversation.

Build the configuration through conversation

There is no required way to begin the conversation. You can start with either a broad goal or a detailed set of requirements.

Start with a general intent

You can describe the outcome without already knowing how the integration should be configured:

"I want our support team in ServiceNow to collaborate with the development team in Jira."

Aida helps translate this goal into concrete requirements by asking about routing, item types, fields, statuses, comments, and other relevant behavior.

This approach is useful when you understand the business process but have not yet designed the complete synchronization.

Start with specific requirements

You can also provide several known requirements at once:

"Send escalated ServiceNow incidents to Jira. Route them to different Jira projects based on the ServiceNow assignment group. Synchronize the summary, description, and priority."

Aida captures the provided information and asks follow-up questions where details are missing. This approach is useful when the integration behaviour has already been designed.

You do not need to describe the complete integration in one message. Start with the information you have and refine it as the conversation progresses. You can correct Aida at any point:

"The Application Support assignment group should route to TMT, not AEM."

Provide exact ticket-system information

Conversation Mode does not yet have direct access to the metadata of the connected ticket systems.

Aida therefore does not automatically know details such as:

• available fields and field types;

• custom fields;

• projects, tables, or item types;

• status values;

• priority values;

• allowed option values.

Provide these details explicitly and use the exact names configured in the ticket system.

For example, To Do, Todo, and TO DO may represent different values. Aida cannot currently validate or automatically correct them against the connected system.

Use exact values when defining mappings:

"Map ServiceNow state In Progress to Jira status In Development."

Also define fallback behaviour where needed:

"When the ServiceNow priority is empty, use Medium in Jira."

Integration subjects

Aida organizes captured requirements into integration subjects. These provide an overview of the areas already discussed and those that still require input.

A completed subject means that requirements have been captured for that area. It does not guarantee that the generated configuration is correct or complete.

You can revisit any subject through the conversation and change its requirements.

Background script generation

Aida continuously regenerates the underlying scripts when requirements change.

A submitted change is not immediately available for inspection or testing. Exalate must first process it and update the scripts.

While scripts are being generated:

• View Scripts is unavailable;

• TestRun is unavailable.

Wait until generation has completed before inspecting or testing the latest configuration.

View the generated scripts

You can inspect the generated outgoing and incoming scripts without leaving Conversation Mode.

This can help you:

• verify how a requirement was implemented;

• troubleshoot an unexpected result;

• review the configuration before publishing;

• determine whether manual scripting is required.

Viewing the scripts does not change the configuration mode. Editing them directly requires switching to Script Mode.

Give Aida implementation instructions

Conversation Mode is primarily requirements-driven, but you can also give Aida direct implementation instructions.

For example:

• "Use an if-else statement instead of a mapping."
• "Add a comment using this exact formatting."
• "Use this Exalate method to retrieve the value."

This can help when the intended behaviour is correct but you want the generated script to use a particular implementation.

Where Aida can apply the instruction, it becomes part of the managed configuration and is retained during later script-generation cycles. Try this before permanently switching to Script Mode.

Configure triggers

Triggers are supported but are configured separately from the conversation.

Triggers determine which items enter synchronization. Conversation Mode defines how those items are processed after synchronization starts.

Trigger configuration works in the same way as in Script Mode.

Test and refine the configuration

Use TestRun to validate the current draft against representative source items.

When the result is not correct:

1. Return to the conversation.
2. Explain what should change.
3. Wait for script generation to complete.
4. Run the test again.

TestRun works in the same way as in Script Mode.

Versioning and publishing

Conversation Mode uses the standard Exalate versioning model.

• Changes are stored in a draft.

• The active configuration remains unchanged until the draft is published.

• Publishing activates the generated scripts.

• Previous versions remain available through the normal version history.

Test the current draft before publishing it.

Switch permanently to Script Mode

Consider switching to Script Mode when:

• the conversation does not produce the required result;

• the generated scripts require changes that Aida cannot apply;

• the integration requires advanced or unsupported scripting;

• you prefer to manage the configuration directly in Groovy.

Before switching, try describing the required implementation directly to Aida. A script-level instruction may resolve the issue without leaving Conversation Mode.

When you switch, the generated scripts are preserved and become the starting point for the Script Mode configuration.

Current limitation

The switch to Script Mode is permanent. You cannot return this connection to Conversation Mode.

Exalate is working toward a hybrid experience that combines conversation and direct scripting in one configuration mode.

When switching, you can provide the reason why Script Mode was required. This feedback helps Exalate identify scenarios that Conversation Mode does not yet handle successfully.

Provide feedback

Feedback is especially valuable while Conversation Mode remains a Lab feature.

Annotate an Aida response

Hover over an Aida response and select the callout action to add an annotation.

Use annotations to report issues such as:

• Aida misunderstood the requirement;

• an important question was not asked;

• the captured requirement is incomplete;

• the generated implementation does not match the requirement;

• the response is unclear.

Every submitted annotation is reviewed by Exalate.

Explain why you switched modes

When switching to Script Mode, provide the reason the conversation could not produce the required result.

This helps identify missing capabilities and recurring failure patterns.

Broader feedback can also be shared through the Exalate Community.

Recommended workflow

1. Select Conversation Mode.
2. Confirm the connection direction.
3. Describe either the overall goal or the known requirements.
4. Answer Aida’s clarification questions.
5. Provide exact ticket-system names and values.
6. Wait for script generation to complete.
7. Configure the trigger separately.
8. Run TestRun with representative items.
9. Refine the requirements and test again.
10. Switch direction and configure the reverse flow when required.
11. Publish the tested draft.
12. Switch to Script Mode only when conversation and implementation instructions cannot produce the required result.

Lab feature considerations

Conversation Mode is publicly available as a Lab feature.

Aida may:

• misunderstand an ambiguous requirement;

• omit behavior that was not specified;

• generate an incorrect mapping;

• use a value that does not exist in the ticket system;

• generate scripts that require further correction.

Review the captured requirements, inspect the generated scripts where necessary, and test representative items before publishing.