Managing Applications and Variables
Routine application housekeeping — listing what exists, creating an application, renaming one, managing the variables workflows depend on — can be done by asking rather than navigating. Every change is staged for your approval first.
Work with applications
List what exists
What applications are in this workspace?
You get each application's name, description, type, and how many workflows it contains, which is usually enough to tell them apart without opening each one.
Create an application
Create an application called Order Processing.
Create an application for customer onboarding and build me a workflow that validates new customer records.
A description is optional but worth giving. It appears in the application list and feeds the generated application description.
The new application appears as pending and marked NEW. Accept it to create it.
Update an application
You can change the name, the description, or both:
Rename this application to Order Processing v2.
Change the description of the Invoicing application to "Handles supplier invoice validation and posting".
The change stays pending until you accept it.
Delete an application
Deleting an application removes everything inside it — workflows, schemas, and resources. It cannot be undone, so it is the most carefully guarded action here.
- Ask for the deletion.
- NxAgent tells you what you would lose: the application's name and how many artifacts it contains.
- Confirm explicitly. It does not proceed on an ambiguous answer.
- Accept the change. The deletion is staged like any other change.
- The deletion is processed last, after everything else in the batch, so nothing else is disrupted on the way.
Deleting an application is permanent. Read the artifact count in the confirmation before you accept.
Work with global variables
Global variables hold values your workflows need but should not hard-code — a base address, a timeout, an account reference, a credential. Set them once, use them everywhere, and change them without editing a workflow.
Variables live in groups
You create a group, not a single variable: a named set of related values. A group called ApiSettings might hold baseUrl, timeout, and apiKey. Grouping keeps related settings together and makes them easier to find later.
Create a variable group called ApiSettings with baseUrl, timeout, and apiKey.
Variable types
| Type | Use it for |
|---|---|
string | Text such as addresses, names, and references |
number | Values that may have decimals |
integer | Whole numbers such as counts, timeouts, and retries |
boolean | True or false switches |
secret | Passwords, keys, and tokens |
Use secret for anything sensitive. It marks the value as protected, and protected values are never printed back to you or into generated documentation.
Variable scopes
| Scope | Meaning |
|---|---|
| Application | The same value wherever the application runs |
| Deployment | Set per environment, so Development, Staging, and Production each get their own |
| Client | Set per client |
Choose Deployment when a value legitimately differs between environments, such as a test address against a live one.
Update and delete
Change the timeout in ApiSettings to 60.
Delete the OldSettings variable group.
As with applications, changes are staged until you accept them.
How you know it worked
Pending changes appear in the preview with their action marked, and the application or variable group exists only once you accept. Deletions state what will be lost before you confirm.
When it does not work
| Symptom | Cause | What to do |
|---|---|---|
| An application will not be created | The workspace already holds the maximum of 10 active applications | Delete an application you no longer need, or move one to the Inactive state |
| A deletion did not proceed | The confirmation was ambiguous | Confirm the deletion explicitly by name |
Next steps
- Building Workflows and Mappings — fill a new application with workflows.
- Managing Variables — the full variables reference.