Concepts and words
Palatine speaks its own words. Each one is explained here in a few lines; the last sections map the words a team brings from Automation Anywhere and name the second set a room can use.
Automations
An automation is anything the room runs: a task, a process or a script. The Automations page lists them in folders, with files (CSV, XLSX, JSON and others) beside them. An automation keeps a permanent identity, so renaming or moving it never breaks what points at it.
Tasks and processes
- A Task does the work: it opens applications, reads the screen, types, clicks, and reads and writes files. You build it as a list of steps in the editor.
- A Process orchestrates: it runs tasks in order with the Run task step, reads its Config, sends notifications and handles errors with Try, Catch and Finally. A process holds orchestration steps only, so the business logic stays in its tasks. A new process starts with Try, Catch and Finally already in place.
- A Script is an automation uploaded as a zip with its own entry point.
Drafts and Releases
Every automation has two sides.
- Drafts are yours alone. You edit a draft, it saves by itself as you work, and nobody else sees it.
- Releases are shared and numbered. Publish turns your draft into the next release (v1, v2 and on) with a note. A release never changes.
- Take back brings the latest release back to your Drafts so you can change it. It stays taken back, locked to you, until you publish again.
Schedules, triggers and queues always start a release, never a draft. An earlier release can be restored as the newest one. Beside each automation the room says where it stands: never published, taken back, changed, latest or earlier release.
Devices and pools
- A Device is a Windows computer with the agent installed and registered to your room. It runs one job at a time unless an administrator allows more.
- A Pool is a named group of devices. A run sent to a pool waits until a member is online and has a free slot, then runs there.
To run unattended, a device needs its Windows credentials, set once under Devices. The agent then signs in to Windows by itself before a run.
Runs
A Run is one execution of an automation on a device. It is queued, then running, and ends done, failed or stopped; it can also be paused and stepped through. Each run keeps its log, a trace of its steps and, when the device records, a video of the screen.
A run can retry by itself when it fails, if its schedule or trigger asks for it. If a device drops off during a run, the run goes back to the queue once.
Schedules
A Schedule starts a release at set times: daily, on chosen weekdays, monthly, every few hours or once, in the time zone you pick. The Schedules page shows a week or a month of the runs schedules started and the runs still planned.
By default a room schedules processes only, so a task is scheduled through a process that runs it. An administrator can change this in Settings.
Two more ways start runs. A trigger fires when a file lands in a folder on a device, or when another system calls its webhook. A work queue holds items, each processed by one run; an item that keeps failing is set aside for a person.
Config and environments
A process carries a Config: keys and values common to every run, plus values per environment, DEV, QA and PRD. A run of a process names its environment, and a schedule or trigger of a process must name one. A step reads a value as $config.Key$, and the editor shows which value each environment gives.
The Config also lists the folders a run creates and who receives each notification. A task run on its own can use the Config of a process. An Automation Anywhere config or event XML file can be imported into it.
Variables and types
Variables are typed. The twelve types are String, Number, Boolean, Datetime, List, Dictionary, Record, Table, Credential, File, Window and Any.
- A variable can be an input, asked for when a run starts, or an output, returned when it ends.
- In a field,
$name$reads a variable. The editor marks a variable whose type does not fit the field before you run. - A variable with no value yet reads as nothing, and the run log warns about it.
- A Credential's password is never written to a log.
KPIs
A KPI is a number an automation reports about the business: invoices processed, amount paid, hours saved. It is declared in the automation, so it is versioned with it. Its value comes from a variable, a Record KPI step, the run's duration, or a formula over other KPIs.
Insights shows them in two views. Operations: runs, success rate, duration and failures. Business: each KPI with the change on the period before, as a chart, and KPIs that share a group as one breakdown. The room's Business dashboard totals value handled, hours saved and items handled across automations, and exports to CSV or XLSX.
The KPI builder reads recent runs and proposes KPIs, each with the fact from the runs behind it; nothing is saved until you add one. A person with the Business role reads Insights, the automations list and runs, and nothing else.
Coming from Automation Anywhere
If your team knows Automation Anywhere, this table maps its words to Palatine's. The room shows only Palatine's words.
| Automation Anywhere | Palatine |
|---|---|
| Control Room | the room |
| Bot Runner | Device |
| Task bot | Task |
| Master bot | Process |
| Bot | automation |
| Check in | Publish |
| Check out | Take back |
| Device pool | Pool |
| Private workspace | Drafts |
| Public workspace | Releases |
The disc words
A room can read in a second set of words: Library for Automations, Disc for Process, Track for Task, Release for the Publish button, and Player for Device. An administrator picks the set under Settings, and the word for the machine can be chosen on its own. These docs use the default words.