4.2 Logging Levels, Robot Logs & Custom Log Fields in REFramework
Key Takeaways
Log Message offers Trace, Info, Warn, Error, and Fatal; the robot logging level filters with Verbose, Trace, Information, Warning, Error, Critical, and Off.
Default logs include Execution Start and End and Transaction Start and End at Information level; Verbose adds activity tracking with variable values.
Add Log Fields attaches key-value pairs to every later log in the job until Remove Log Fields removes them; fields such as jobId and processName cannot be overridden.
REFramework adds logF_BusinessProcessName in Initialization and adds then removes logF_TransactionStatus, Number, ID, Field1, and Field2 in SetTransactionStatus.xaml.
Set out_TransactionID and the two transaction fields in GetTransactionData.xaml so every log line identifies the business record.
4.2 Logging Levels, Robot Logs & Custom Log Fields in REFramework
Core Concept: Every UiPath robot writes structured logs through NLog. Some are default logs that the robot writes by itself, and some are user-defined logs from activities such as Log Message. Add Log Fields attaches extra key-value pairs to every later log line, and REFramework uses this to tag each transaction. The exam description lists "Use Custom Log Fields in REFramework projects" explicitly, so know both the mechanism and the fields the template adds.
Two Scales: Activity Levels and Robot Levels
The Log Message activity offers five levels: Trace, Info, Warn, Error, and Fatal. The robot logging level (set per process or per robot in Orchestrator, and in Assistant) acts as a filter with seven values, from most to least detailed:
| Robot logging level | What gets logged |
|---|---|
| Verbose | Everything at Trace and above, plus workflow tracking: every activity's start and end, with variable and argument values |
| Trace | Messages at Trace level and above |
| Information (default) | Information and above |
| Warning | Warning and above |
| Error | Error and above |
| Critical | Critical only (Fatal messages from Log Message map here) |
| Off | Nothing |
The order is Verbose < Trace < Information < Warning < Error < Critical < Off. If a process runs at Warning, a Log Message at Info is dropped, while Warn, Error, and Fatal messages are kept. Verbose logs can include variable values, which is why activities have a Private property that stops their values from being logged at Verbose level.
Default Logs and Their Fields
The robot writes these default logs without any activity in your workflow:
| Default log | Level | Notable fields |
|---|---|---|
| Execution Start | Information | processName, processVersion, jobId |
| Execution End | Information | totalExecutionTime, totalExecutionTimeInSeconds |
| Transaction Start | Information | queueName, transactionID, transactionState |
| Transaction End | Information | transactionStatus, transactionExecutionTime |
| Error Log | Error | Written when execution hits an error and stops |
| Debugging Log | Trace | Written only when the level is Verbose; contains activityInfo with DisplayName, State, and Activity |
Default logs carry logType = Default, and logs from Log Message or Write Line carry logType = User. Every log also has default fields such as message, level, timeStamp, fileName, jobId, processName, robotName, and machineName. Fields such as jobId, processName, processVersion, and robotName cannot be overridden with Add Log Fields.
Add Log Fields and Remove Log Fields
- Add Log Fields adds user-defined key-value pairs to every subsequent log in the job, default and user-defined alike, until they are removed.
- Remove Log Fields removes them by name.
This matters for traceability. After you add InvoiceNumber = "INV-1001", a selector error thrown three workflows deeper still carries the invoice number in Orchestrator, Elasticsearch, or whatever sink the logs go to. Remove per-transaction fields at the end of each transaction, or the next item's logs will show stale values.
How REFramework Uses Custom Log Fields
The template uses both activities in two places:
- Initialization (first run). Add Log Fields adds
logF_BusinessProcessName, whose value comes from the Settings sheet ofConfig.xlsx. Several sub-processes of one business process, such as a Dispatcher and a Performer, can share the same value, so their logs can be grouped in dashboards. - SetTransactionStatus.xaml. For each outcome (success, business exception, system exception) the template adds a set of transaction fields, writes the result message, and removes them:
| Field | Filled from |
|---|---|
logF_TransactionStatus | "Success", "BusinessException", or "ApplicationException" |
logF_TransactionNumber | io_TransactionNumber |
logF_TransactionID | in_TransactionID, set in GetTransactionData.xaml |
logF_TransactionField1 | in_TransactionField1, set in GetTransactionData.xaml |
logF_TransactionField2 | in_TransactionField2, set in GetTransactionData.xaml |
So the customization point is GetTransactionData.xaml: assign out_TransactionID and the two extra fields to business values (for example, invoice number, vendor, and amount). The template's default is to use the current timestamp as the ID and leave the other fields empty, which is not useful for searching. Adding your own fields, such as logF_CustomerSegment, follows the same pattern: add them where the value becomes known and remove them before the next transaction.
Where Logs Go
- Locally: execution logs are written to
%LocalAppData%\UiPath\Logsfor user-mode robots. The NLog configuration file in the robot's installation folder controls local targets and rotation. - Orchestrator: logs at or above the process's level are sent to Orchestrator and appear on the Logs page and in job details.
- External sinks: NLog targets can also send logs to systems such as Elasticsearch or a SQL database.
Good practice is to log business milestones at Info, recoverable anomalies at Warn, failures at Error, never log secrets, and keep Verbose for short diagnostic runs.
Common Exam Traps
- "Debug" is not a Log Message level; the levels are Trace, Info, Warn, Error, and Fatal.
- Raising the robot level to Verbose adds activity tracking. It does not change what Log Message activities write.
- Custom fields added with Add Log Fields stay on every later log until you remove them, including logs written after an exception.
logF_BusinessProcessNamecomes from the Settings sheet, not from Constants or Assets.
A developer wants every log line produced while a queue item is processed, including errors thrown deep inside invoked workflows, to contain the customer ID. What is the most maintainable approach?
Concatenate the customer ID into the text of every Log Message activity.
Use Add Log Fields with a CustomerID field when the item is retrieved, and Remove Log Fields when the transaction ends.
Store the customer ID in a Text asset that the robot reads before each log.
Edit the robot NLog configuration to add a fixed CustomerID value.
A process runs in Orchestrator with the logging level set to Warning. During the job, Log Message activities write one message at Info, one at Warn, and one at Error. Which messages are kept?
All three, because Log Message ignores the robot level.
Only the Info message, because Warning keeps messages below it.
None, because unattended robots send only Critical logs.
The Warn and Error messages.
In the standard REFramework template, where should a developer set the value that appears in logF_TransactionID for each transaction?
In GetTransactionData.xaml, by assigning out_TransactionID (and optionally out_TransactionField1 and out_TransactionField2) to business values.
On the Assets sheet of Config.xlsx, one row per transaction.
In the End Process state, after all transactions are finished.
In Orchestrator, through the queue's Reference setting only.
Sections you finish are checked off in the contents.