Working with coding agents in Creatio
The Creatio AI app development toolkit is available starting with Creatio release 8.3.4 and is compatible with versions 8.3.0 and later. If you have any feedback, contact us at: beta@creatio.com. All feedback is appreciated.
This article shows what kinds of tasks you can accomplish with coding agents in Creatio and how to write prompts that produce accurate results. Typical use cases include creating a new app from a business description, extending an existing app, adding validation logic, reacting to field changes, applying date-based rules, calculating derived values, and reusing logic across multiple pages.
Create a new app
Use the toolkit when you want to describe an app in business terms and get the initial application structure generated for you.
Create a vendor onboarding app with two sections: Vendors and Vendor Requests.
Create a vendor onboarding app. It should include Vendors and Vendor Requests. Vendor Requests must have request number, request date, status, owner, vendor, requested services, and approval comment. Generate a request page and a vendor page. Add lookups where needed and make the app ready for data entry.
Extend an existing app
Use the toolkit to add new sections or functionality to an existing application without rebuilding it from scratch.
Add a Warranty Claims section to the existing Case Management app.
Extend the existing Case Management app with a new Warranty Claims section. Reuse existing Account and Contact data where possible. Add a claim form page with claim number, product, claim reason, date opened, resolution date, and status.
Prevent invalid data from being saved
Use the toolkit to implement validation logic that protects data quality. Typical use cases include validating text format, enforcing length limits, enforcing numeric rules, comparing several fields, validating totals in expanded lists, requiring meaningful input, and checking uniqueness.
Validate text format and length on a customer form.
On the customer form, Full name must contain only Latin letters and spaces. Phone number must start with 380 and contain exactly 12 digits. Registration code must contain 8 to 10 digits. If the value is invalid, show a clear message and prevent saving.
Enforce character limits on a job request form.
In the Job request form page, Job number field must contain no more than 10 characters. Description field must be limited to 500 characters, and the page must show that limit near the field.
Enforce numeric rules on a Loan Application app.
In the Loan Application app, Age must be 18 or higher. Requested amount cannot be below 0. Score can only be 0, 17, or any value from 100 to 1000.
Compare field values on a warehouse operation form.
In the Warehouse Operation form, Issued quantity cannot be greater than Available quantity. Internal amount and External amount together must equal Total amount.
Validate totals across expanded list rows in the Project Allocation app.
In the Project Allocation app, the total allocation across expanded list rows cannot exceed 100 percent. The sum of all expanded list rows must also match the planned allocation in the main record.
Require meaningful text input on a citizen request form.
In the Citizen Request form, Subject is considered filled out only if it contains meaningful text. Empty or spaces-only values are invalid.
Check email uniqueness across contacts.
In the Contact Management app, email must be unique across contacts. When the user changes the email, check whether it is already used by another contact. When editing an existing contact, its own current email must remain valid.
React immediately when the user changes a field
Use the toolkit when page logic must run during user interaction, not only on save. Typical use cases include clearing dependent fields, recalculating values immediately, blocking stage changes when conditions are not met, and explaining why Creatio changed a field value.
Clear a dependent field and block a stage transition based on field values.
In the Procurement Request page, when Standard destination changes, clear Loan category immediately and explain why. When the request is moved to Approved, block the change if Purchase type is Below threshold and Budget is greater than 50000.
Apply date-based logic
Use the toolkit to implement date-related validation and page behavior. Typical use cases include enforcing that an end date cannot be earlier than a start date, a planned date cannot be in the past, or a birth date must correspond to a minimum age.
Validate date fields and enforce a minimum age on the Event Management app.
In the Event Management app, End date cannot be earlier than Start date. Planned date cannot be in the past. Birth date must correspond to a person who is at least 18 years old. Prevent saving when the rule is violated and show a clear explanation.
Calculate and display derived values
Use the toolkit when the page must not only store data but also calculate and present values in a readable format. Typical use cases include calculating fees, totals, or percentages, showing read-only derived values, formatting calculated values for easier reading, and combining calculations with validation rules.
Create a loan application form that combines validation, conditional logic, and calculated read-only fields.
Create a Loan Application Management app.
On the application form, add a Loan details section with these rules:
- Name: only Latin letters are allowed, and the value must be displayed in uppercase on the page.
- Age: must be 18 or higher.
- Credit score: must be between 100 and 1000. For scores below 500, show a down arrow icon. For scores of 500 or higher, show an up arrow icon.
- Loan amount: must not exceed 5000 if the credit score is below 500.
- Loan start and end dates: the loan duration must be at least 1 month, the end date must be later than the start date, and the start date cannot be earlier than today.
Add a Loan calculations section with read-only fields calculated from the entered data:
- Fee: 3% of the loan amount, displayed as "3% from 100$ = 3$".
- Total loan amount: Loan amount plus Fee, displayed as "100$ + 3$ = 103$".
Each validation or restriction must be shown as an inline hint during form editing and must prevent saving the form if the rule is violated.
This example shows how one prompt can combine validation, visual behavior, conditional logic, date logic, calculations, formatted output, and save prevention.
Improve how values are shown on the page
Use the toolkit when the goal is to present data more clearly rather than validate it. Typical use cases include combining several fields into one readable caption, showing user-friendly labels instead of stored codes, formatting progress, percentages, or status text, and deriving display-only values without changing stored data.
Combine multiple fields into a single readable caption on a request page.
On the request page, show a display field that combines request number, status, and created date into one readable caption.
Display a stored code as a readable label on a customer page.
On the customer page, display customer type as a readable label instead of the stored code value.
Show fulfillment progress as a formatted percentage and status text on an order page.
On the order page, show fulfillment progress as a formatted percentage and a textual state such as Not started, In progress, or Complete.
Reuse the same logic across multiple pages
Use the toolkit when the same logic must behave consistently in different parts of the application.
Apply the same validation rule to two different pages.
Create a Customer page and a Partner page. On both pages, Registration code must contain exactly 8 digits. The behavior and message must be the same everywhere.
Best practices for writing effective prompts
The toolkit produces better results when the prompt describes the requirement precisely. Include the following in your prompt:
- the app, page, or form to create or update
- the field, section, detail, or stage where the behavior applies
- the exact rule
- when the behavior should run
- what the user should see
- whether invalid input must block saving
- how calculated or derived values should be shown
Use this pattern as a starting point:
Create or update the [app, page, or form].
Apply this behavior to [field, section, detail, or stage].
The rule is: [exact condition].
Run it [on change, on save, on stage change, or for display].
If the rule fails, [show message, clear field, block save, or block transition].
For calculated or display values, use: [formula, formatting, read-only behavior, icon, or label].
Additional tips:
- describe the business result, not the implementation approach
- specify dependencies between fields
- include examples of expected output for calculated or formatted values
- state clearly whether the rule should prevent saving