Generate
SailPoint Rule using AI in a format that is compatible with the UI created rule
in Yasas DevX Suite.
Yasas
DevX Suite
Yasas DevX Suite introduces an
AI-powered SailPoint Rule Generator designed to translate simple natural
language prompts directly into production-ready rules.
However, merely generating raw XML or BeanShell code is not enough of a solution. The true innovation lies in solving a much bigger challenge: How do you ensure AI-generated rules behave exactly like rules built manually in the UI?. Yasas DevX Suite bridges this gap, ensuring that AI-generated rules can be seamlessly saved, edited, and reopened within the Rule Builder without ever breaking
Instead of just spitting out a block of XML code,
Yasas DevX Suite takes a comprehensive, multi-layered approach to rule
generation.
To ensure the AI-generated rule is structurally
identical to a manually created one, the system generates five distinct
components:
● XML Rule Code
● Data Elements JSON
● Flow Conditions JSON
● Custom Functions JSON
● Metadata for Reconstruction
Here is a step-by-step breakdown of how the workflow
operates:
The
process begins when a user enters a plain-text prompt, such as: "Generate
a correlation rule using email, convert to lowercase, trim spaces, and map to
identity attribute employeeNumber".
This
prompt is sent to an n8n workflow where an Intent Extraction Agent (the first
LLM node) parses the natural language into a strictly enforced, structured JSON
intent to guarantee predictable parsing.
Before generating any code, the workflow validates
whether all mandatory fields (like the Source Attribute and Identity Attribute)
are present.
If critical information is missing, the system intelligently returns a clarification response asking the user for the missing details, effectively preventing invalid rule generation attempts
Once
validated, the system builds the core internal structures that mirror the
manual UI builder:
A.
Data Elements
These
represent each visual node you would typically see in the manual rule builder,
successfully replicating transformation steps
Example:
[
{
"name": "rawValue1",
"sourceType": "SourceAttributes",
"sourceAttribute": "email"
},
{
"name": "transformed",
"sourceType": "Added_Parameter",
"selectedFunction": "toLowerCase",
"selectedDataElement": "rawValue1"
}
]
This
mirrors how manual UI-created rules store transformation steps.
B.
Flow Conditions JSON
This
represents the visual IF/ELSE logic, allowing the system to reconstruct the
rule-builder's flowchart
Example:
[
{
"type": "if",
"conditions": [
{
"dataElement": "rawValue1",
"comparison": "isNotNull"
}
],
"trueBranch": [
{ "name": "transformed" }
]
}
]
Built
via buildFlow() to reconstruct rule-builder flowchart.
C.
Metadata
This
acts as the ultimate "single source of truth". XML alone cannot
reconstruct a visual UI state; the metadata stores the exact details needed for
the edit screen, such as selected dropdowns, chosen operations, substring
indices, function ordering, and concatenation chains
Example:
{
"sourceAttribute": ["email"],
"identityAttribute": "employeeNumber",
"transformChain": [
{ "op": "toLowerCase" },
{ "op": "trim" }
],
"finalValue": "transformed"
}
Finally, once the internal model is built, the
AI/Template engine generates the final SailPoint XML. Because the AI generates
the exact same JSON structures as the manual UI, the magic happens when a user
wants to make a change.
When a user clicks "Edit," the UI reads the
stored JSON and perfectly reconstructs the builder. The edit screen loads
flawlessly with every dropdown pre-selected, every function chain restored, and
the entire flowchart rebuiltallowing the user to continue tweaking the rule
normally
Sricharan
KT