- Démarrage
- Activités
- Concevoir des workflows de longue durée
- Start Job And Get Reference
- Wait for Job and Resume
- Add Queue Item And Get Reference
- Wait For Queue Item And Resume
- Wait for Form Task and Resume
- Reprendre après le délai
- Assign Tasks
- Create External Task
- Wait For External Task and Resume
- Terminer la tâche
- Forward Task
- Get Form Tasks
- Get Task Data
- Obtenir des tâches d’application
- Add Task Comment
- Update Task Labels
- Créer une tâche d'application
- Attendre la tâche d'application et reprendre (Wait For App Task and Resume)
- Configurer le minuteur de tâches (Configure task timer)
- Actions
- Autopilot dans Action Center - Aperçu
- Processus (Processes)
- Notifications
- Audit
Diagnostic feedback tool in Action Center's Validation and Classification Stations, the data each report sends, how values are obfuscated, and who can access them.
The Report an issue button is a diagnostic feedback tool available in two Action Center screens: the Validation Station, which opens inside a Document Validation action, and the Classification Station, which opens inside a Document Classification action. It lets a reviewer describe a problem and send it to the UiPath Document Understanding engineering team without leaving the screen. It is available only in Automation Cloud.
Both stations use the same button and the same dialog. They differ in one respect only: the data each one can attach, because validation and classification produce different results. Everything else on this page applies to both.
Finding the button
The button floats above the document and can be dragged to any position, so it does not have to cover the content being reviewed. Its position is remembered for the next visit.
First visit
On a reviewer's first visit, a callout introduces the button and points out that it can be moved. Dismissing the callout with Got it stops it from appearing again.
What the dialog contains
Selecting the button opens a dialog with three independent parts: a description of the problem, an optional diagnostic data attachment, and an optional version rollback. Each part is explained in the following sections.
Describing the problem
The What went wrong? field holds a free-text description of the problem. It is the only required part of the dialog: until it contains text, Send report stays unavailable.
This field is sent exactly as it is typed. Unlike the data described in the following section, it is not obfuscated, aliased, or filtered in any way.
Anything typed into the description is transmitted verbatim. Descriptions of the problem and the steps that led to it are what the engineering team needs.
Sending the results and taxonomy
The data checkbox is selected by default. Its label names what each station attaches:
- In the Validation Station, Send the Extraction Result and Taxonomy. The taxonomy is the document type definition being validated against, with its groups, categories, fields, and field types. The extraction result is what the model returned for the document: which fields were found, the confidence scores, and where on the page each value was located.
- In the Classification Station, Send the Classification Result and Taxonomy. The document types are the definitions a document can be classified as. The classification result is what the classifier returned: which document type each set of pages was assigned to, which pages belong to it, and how confident the classifier was.
In both stations the document file itself is never included, and both structures reflect the state as the screen loaded them. Changes a reviewer makes afterward are not sent.
Neither structure is transmitted at the moment Send report is selected: the station reloads, and the structures are attached during that reload. This is why the screen refreshes after a report that includes data.
For exactly what these structures look like once obfuscated, see Examples of the data that is sent.
Trying a previous version
The Try a previous version checkbox reveals the recent builds of the station that a reviewer can switch to, which helps when a problem appeared only after a recent update. The list shows each build's publication date and build identifier, with the active build marked CURRENT.
Choosing a build applies it the next time the station loads. A rollback lasts up to 30 days, after which the newest build is restored automatically. Once a reviewer is on an older build, the dialog also offers Return to the latest version to end the rollback early.
This option is a display preference stored in the browser. It affects only which version of the station's interface loads, for the reviewer who chose it, on that browser. It does not change the document, the results, the taxonomy, or anything stored in Orchestrator, and it does not send any document data.
What data is sent
Two separate transmissions are involved when a report is submitted:
- The report itself is always sent. It carries the free-text description, whether the data checkbox was selected, and which rollback option was chosen.
- The taxonomy and the extraction or classification result are sent only when the data checkbox stays selected.
Both stations also attach the same identifying context: the document ID and Action Center task ID, which are UiPath-generated identifiers that let a report be matched to the session it came from; the organization name, tenant name, region, and build version, which identify the environment; and an opaque user identifier, described in Who can access this data.
The two stations differ in what the data structures contain.
Station de validation
| Données | Sent to UiPath? | Détails (Details) |
|---|---|---|
| The document file (PDF or image) | Jamais | Not part of this feature |
| The free-text problem description | Yes, verbatim | Not obfuscated or filtered |
| Extracted values of Boolean, Date, Number, Set, and Monetary Quantity fields | Yes, verbatim | Preserved because these types hold structured values rather than free text |
| Extracted values of all other field types, including text read from the document | Non (No) | Replaced with a same-shape random substitute |
| Field, group, category, and document type names | Non (No) | Replaced with sequential aliases, for example f1, g1, dt1 |
| Bounding box positions, page dimensions, and confidence scores | Oui (Yes) | These describe layout and model behavior, not document content |
Station de classification
| Données | Sent to UiPath? | Détails (Details) |
|---|---|---|
| The document file (PDF or image) | Jamais | Not part of this feature |
| Text read from the document | Jamais | Classification records which pages belong to a document type, not their contents |
| The free-text problem description | Yes, verbatim | Not obfuscated or filtered |
| Document type, group, category, and field names | Non (No) | Replaced with sequential aliases, for example dt1, g1, c1, f1 |
| The classifier's name | Non (No) | Replaced with a same-shape random substitute |
| Page ranges, page counts, and page dimensions | Oui (Yes) | Preserved because a decoded session cannot be replayed if its page ranges no longer match |
| Bounding box positions and confidence scores | Oui (Yes) | These describe layout and classifier behavior, not document content |
A Classification Station report carries less document-derived data than a Validation Station one. Validation sends the values extracted from a document, some of which are preserved as they are. Classification produces no extracted values at all, so nothing read from the document is transmitted.
Ce qui n'est jamais collecté
The following are never captured, generated, or transmitted by this feature, in either station:
- HTTP Archive (HAR) files. The feature does not generate a HAR file, and no HAR file is ever collected, requested, or uploaded.
- Network traffic of the surrounding page. The telemetry library's automatic request tracking is deliberately switched off in both stations so that Action Center's own network activity is not captured. Only each station's own service calls are recorded, as request names, response codes, and durations.
- Screenshots and screen recordings. No image of the screen is produced at any point.
- The document file, its text layer, or its page images.
- Cookies, browser storage contents, or credentials.
No data beyond what the preceding tables list is collected by this feature.
Examples of the data that is sent
The obfuscation happens in the browser, before anything is transmitted. Three transformations are applied in both stations:
- Names become aliases. Groups, categories, document types, fields, and table columns are replaced with sequential aliases such as
g1,c1,dt1,f1, andcol1. Relationships survive, so engineering can still see the shape of a taxonomy, but no customer-authored name does. - Redacted values become same-shape substitutes. Every letter becomes a random letter and every digit a random digit, while punctuation, spacing, and length survive, so a purchase order held in a text field, such as
PO-4471/A, becomes something likeqm-8213/x. The substitution is random rather than a fixed hash, so two identical values never produce the same substitute. - Property names are shortened. Long names are aliased to keep the payload small enough to transmit.
Substitution applies only to the values that the preceding tables list as not sent. In the Validation Station, values of Number, Date, Boolean, Set, and Monetary Quantity fields are transmitted as they are, so the digits inside them are never replaced. In the Classification Station, page ranges are kept as they are, because random digits would produce ranges that no longer match the document and a reported session could not be replayed.
Validation Station structures
Taxonomie
A taxonomy fragment as it exists in the browser:
{
"DataContractVersion": "1.0.0",
"DocumentTypes": [
{
"DocumentTypeId": "Finance.AccountsPayable.VATInvoice",
"Group": "Finance",
"Category": "AccountsPayable",
"Name": "VAT Invoice",
"Fields": [
{
"FieldId": "Finance.AccountsPayable.VATInvoice.VendorName",
"FieldName": "Vendor Name",
"Type": "Text"
},
{
"FieldId": "Finance.AccountsPayable.VATInvoice.TotalAmount",
"FieldName": "Total Amount",
"Type": "MonetaryQuantity"
}
]
}
]
}
{
"DataContractVersion": "1.0.0",
"DocumentTypes": [
{
"DocumentTypeId": "Finance.AccountsPayable.VATInvoice",
"Group": "Finance",
"Category": "AccountsPayable",
"Name": "VAT Invoice",
"Fields": [
{
"FieldId": "Finance.AccountsPayable.VATInvoice.VendorName",
"FieldName": "Vendor Name",
"Type": "Text"
},
{
"FieldId": "Finance.AccountsPayable.VATInvoice.TotalAmount",
"FieldName": "Total Amount",
"Type": "MonetaryQuantity"
}
]
}
]
}
The same fragment as it is transmitted:
{
"type": "taxonomy",
"t": {
"d": "1.0.0",
"D": [
{
"i": "g1.c1.dt1",
"g": "g1",
"c": "c1",
"n": "g1.c1.dt1",
"F": [
{ "fi": "g1.c1.dt1.f1", "fn": "g1.c1.dt1.f1", "T": "txt" },
{ "fi": "g1.c1.dt1.f2", "fn": "g1.c1.dt1.f2", "T": "mq" }
]
}
]
},
"i": { "DisplayMode": "compact" }
}
{
"type": "taxonomy",
"t": {
"d": "1.0.0",
"D": [
{
"i": "g1.c1.dt1",
"g": "g1",
"c": "c1",
"n": "g1.c1.dt1",
"F": [
{ "fi": "g1.c1.dt1.f1", "fn": "g1.c1.dt1.f1", "T": "txt" },
{ "fi": "g1.c1.dt1.f2", "fn": "g1.c1.dt1.f2", "T": "mq" }
]
}
]
},
"i": { "DisplayMode": "compact" }
}
Every customer-authored name is gone: Finance became g1, AccountsPayable became c1, VATInvoice became dt1, and both field names became f1 and f2. What remains is the structure and the field types, txt for Text and mq for Monetary Quantity.
Extraction result
An extraction result as it exists in the browser:
{
"DocumentId": "7f3c1e90-4a2b-4c8d-9e11-6b5a0d2f8c43",
"ResultsVersion": 1,
"ResultsDocument": {
"Language": "eng",
"DocumentGroup": "Finance",
"DocumentCategory": "AccountsPayable",
"DocumentTypeId": "Finance.AccountsPayable.VATInvoice",
"DocumentTypeName": "VAT Invoice",
"Fields": [
{
"FieldId": "Finance.AccountsPayable.VATInvoice.VendorName",
"FieldName": "Vendor Name",
"FieldType": "Text",
"OperatorConfirmed": true,
"Values": [
{
"Value": "ACME Corporation Ltd",
"Confidence": 0.987,
"OcrConfidence": 0.994,
"DataSource": "Extraction",
"Reference": {
"Tokens": [
{ "Page": 0, "PageWidth": 612, "PageHeight": 792, "Boxes": [[72.4, 118.9, 143.2, 12.7]] }
]
}
}
]
},
{
"FieldId": "Finance.AccountsPayable.VATInvoice.TotalAmount",
"FieldName": "Total Amount",
"FieldType": "MonetaryQuantity",
"Values": [
{ "Value": "1416.00", "Confidence": 0.912, "DataSource": "Extraction" }
]
}
]
}
}
{
"DocumentId": "7f3c1e90-4a2b-4c8d-9e11-6b5a0d2f8c43",
"ResultsVersion": 1,
"ResultsDocument": {
"Language": "eng",
"DocumentGroup": "Finance",
"DocumentCategory": "AccountsPayable",
"DocumentTypeId": "Finance.AccountsPayable.VATInvoice",
"DocumentTypeName": "VAT Invoice",
"Fields": [
{
"FieldId": "Finance.AccountsPayable.VATInvoice.VendorName",
"FieldName": "Vendor Name",
"FieldType": "Text",
"OperatorConfirmed": true,
"Values": [
{
"Value": "ACME Corporation Ltd",
"Confidence": 0.987,
"OcrConfidence": 0.994,
"DataSource": "Extraction",
"Reference": {
"Tokens": [
{ "Page": 0, "PageWidth": 612, "PageHeight": 792, "Boxes": [[72.4, 118.9, 143.2, 12.7]] }
]
}
}
]
},
{
"FieldId": "Finance.AccountsPayable.VATInvoice.TotalAmount",
"FieldName": "Total Amount",
"FieldType": "MonetaryQuantity",
"Values": [
{ "Value": "1416.00", "Confidence": 0.912, "DataSource": "Extraction" }
]
}
]
}
}
The same result as it is transmitted:
{
"type": "extraction",
"e": {
"d": "4b9f7a21-8c6e-1d3f-5a44-2e8b9c1f0d76",
"rv": 1,
"rd": {
"l": "eng",
"g": "g1",
"c": "c1",
"i": "g1.c1.dt1",
"n": "g1.c1.dt1",
"F": [
{
"fi": "g1.c1.dt1.f1",
"fn": "g1.c1.dt1.f1",
"ft": "txt",
"o": true,
"V": [
{
"va": "xqmp lwzkqmpxrjd vbn",
"cf": 0.987,
"oc": 0.994,
"ds": "ext",
"r": { "tk": [ { "p": 0, "pw": 612, "ph": 792, "bx": [[72, 119, 143, 13]] } ] }
}
]
},
{
"fi": "g1.c1.dt1.f2",
"fn": "g1.c1.dt1.f2",
"ft": "mq",
"V": [ { "va": "1416.00", "cf": 0.912, "ds": "ext" } ]
}
]
}
}
}
{
"type": "extraction",
"e": {
"d": "4b9f7a21-8c6e-1d3f-5a44-2e8b9c1f0d76",
"rv": 1,
"rd": {
"l": "eng",
"g": "g1",
"c": "c1",
"i": "g1.c1.dt1",
"n": "g1.c1.dt1",
"F": [
{
"fi": "g1.c1.dt1.f1",
"fn": "g1.c1.dt1.f1",
"ft": "txt",
"o": true,
"V": [
{
"va": "xqmp lwzkqmpxrjd vbn",
"cf": 0.987,
"oc": 0.994,
"ds": "ext",
"r": { "tk": [ { "p": 0, "pw": 612, "ph": 792, "bx": [[72, 119, 143, 13]] } ] }
}
]
},
{
"fi": "g1.c1.dt1.f2",
"fn": "g1.c1.dt1.f2",
"ft": "mq",
"V": [ { "va": "1416.00", "cf": 0.912, "ds": "ext" } ]
}
]
}
}
}
Three details are worth noting in this example:
- The vendor name
ACME Corporation Ltdbecamexqmp lwzkqmpxrjd vbn. The word count, word lengths, and spacing survive; the content does not. - The monetary value
1416.00was transmitted unchanged, because Monetary Quantity is one of the structured types listed in the preceding table. On its own it carries no field name, no vendor, and no document content, although the telemetry entry around it does identify the document and task it came from. - The document identifier was obfuscated inside this payload, and box coordinates were rounded to whole numbers to reduce size.
Classification Station structures
Types de documents
A document type as it exists in the browser:
{
"DataContractVersion": "1.0.0",
"DocumentTypes": [
{
"DocumentTypeId": "Finance.AccountsPayable.VATInvoice",
"Group": "Finance",
"Category": "AccountsPayable",
"Name": "VAT Invoice",
"Fields": [
{
"FieldId": "Finance.AccountsPayable.VATInvoice.VendorName",
"FieldName": "Vendor Name",
"Type": "Text"
}
]
}
]
}
{
"DataContractVersion": "1.0.0",
"DocumentTypes": [
{
"DocumentTypeId": "Finance.AccountsPayable.VATInvoice",
"Group": "Finance",
"Category": "AccountsPayable",
"Name": "VAT Invoice",
"Fields": [
{
"FieldId": "Finance.AccountsPayable.VATInvoice.VendorName",
"FieldName": "Vendor Name",
"Type": "Text"
}
]
}
]
}
The same document type as it is transmitted:
{
"type": "cs-taxonomy",
"t": {
"d": "1.0.0",
"D": [
{
"i": "g1.c1.dt1",
"g": "g1",
"c": "c1",
"n": "g1.c1.dt1",
"F": [
{ "fi": "g1.c1.dt1.f1", "fn": "g1.c1.dt1.f1", "T": "txt" }
]
}
]
},
"i": { "EnablePageReordering": true }
}
{
"type": "cs-taxonomy",
"t": {
"d": "1.0.0",
"D": [
{
"i": "g1.c1.dt1",
"g": "g1",
"c": "c1",
"n": "g1.c1.dt1",
"F": [
{ "fi": "g1.c1.dt1.f1", "fn": "g1.c1.dt1.f1", "T": "txt" }
]
}
]
},
"i": { "EnablePageReordering": true }
}
Classification result
A classification result as it exists in the browser:
{
"Classifications": [
{
"DocumentId": "7f3c1e90-4a2b-4c8d-9e11-6b5a0d2f8c43",
"DocumentTypeId": "Finance.AccountsPayable.VATInvoice",
"ClassifierName": "Invoice-Classifier-2",
"Confidence": 0.964,
"OcrConfidence": 0.991,
"DocumentBounds": {
"StartPage": 0,
"PageCount": 3,
"PageRange": "1-3"
},
"Reference": {
"TextStartIndex": 0,
"TextLength": 4821,
"Tokens": [
{ "Page": 0, "PageWidth": 612, "PageHeight": 792, "Boxes": [[72.4, 118.9, 143.2, 12.7]] }
]
}
}
]
}
{
"Classifications": [
{
"DocumentId": "7f3c1e90-4a2b-4c8d-9e11-6b5a0d2f8c43",
"DocumentTypeId": "Finance.AccountsPayable.VATInvoice",
"ClassifierName": "Invoice-Classifier-2",
"Confidence": 0.964,
"OcrConfidence": 0.991,
"DocumentBounds": {
"StartPage": 0,
"PageCount": 3,
"PageRange": "1-3"
},
"Reference": {
"TextStartIndex": 0,
"TextLength": 4821,
"Tokens": [
{ "Page": 0, "PageWidth": 612, "PageHeight": 792, "Boxes": [[72.4, 118.9, 143.2, 12.7]] }
]
}
}
]
}
The same result as it is transmitted:
{
"type": "classification",
"c": {
"K": [
{
"d": "4b9f7a21-8c6e-1d3f-5a44-2e8b9c1f0d76",
"i": "g1.c1.dt1",
"cn": "wmqpjxk-Kqzmwpxjmb-7",
"cf": 0.964,
"oc": 0.991,
"b": {
"sp": 0,
"pc": 3,
"pr": "1-3"
},
"r": {
"ti": 0,
"tl": 4821,
"tk": [
{ "p": 0, "pw": 612, "ph": 792, "bx": [[72, 119, 143, 13]] }
]
}
}
]
}
}
{
"type": "classification",
"c": {
"K": [
{
"d": "4b9f7a21-8c6e-1d3f-5a44-2e8b9c1f0d76",
"i": "g1.c1.dt1",
"cn": "wmqpjxk-Kqzmwpxjmb-7",
"cf": 0.964,
"oc": 0.991,
"b": {
"sp": 0,
"pc": 3,
"pr": "1-3"
},
"r": {
"ti": 0,
"tl": 4821,
"tk": [
{ "p": 0, "pw": 612, "ph": 792, "bx": [[72, 119, 143, 13]] }
]
}
}
]
}
}
Three details are worth noting in this example:
- The document type became the alias
g1.c1.dt1, the same alias used in the document-type payload, so a decoded result still lines up with a decoded taxonomy. - The classifier name was replaced with a same-shape substitute, while the page range
1-3, the page count, and the page dimensions were transmitted unchanged. - The document identifier was obfuscated inside this payload, and box coordinates were rounded to whole numbers to reduce size.
How the data reaches UiPath
Each obfuscated structure is serialized, compressed, and split into numbered chunks of at most 7,500 characters each, because the telemetry backend limits the size of a single property. Each chunk is transmitted as its own entry in the following form, so one report can span more than one telemetry entry, reassembled later by their shared correlation ID:
correlationId|chunkNumber|totalChunks|compressedData
mf3k9a-x7q2p1|1|2|N4IgLgngDgpiBcIQBs2CAWwKYCcDOA9gK4A2AhgHYCeAdg...
correlationId|chunkNumber|totalChunks|compressedData
mf3k9a-x7q2p1|1|2|N4IgLgngDgpiBcIQBs2CAWwKYCcDOA9gK4A2AhgHYCeAdg...
If a payload would need more chunks than the limit allows, it is dropped in full rather than sent in part, because an incomplete payload cannot be decoded. A single marker entry is recorded in its place.
Who can access this data
Reports reach UiPath's Application Insights telemetry pipeline, in the same region as the tenant's Document Understanding deployment. Access is limited to the UiPath Document Understanding engineering team, which uses reports only to diagnose and fix the problems described in them. Reports are not shared with any third party, and they are never sent to the vendor or partner that built the automation.
What identifies a report
Each report is accompanied by the organization name, tenant name, region, and build version, so that engineering knows which environment it came from, together with an opaque user identifier taken from the reviewer's access token. That identifier is a value such as a3f9c1e2-7b04-4d58-9a11-6c2e8f0b5d73.
The identifier exists for one purpose: to group the events of a single session, so that engineering can follow the sequence of actions that led to a problem rather than seeing one isolated event. It holds no name, no email address, and no other contact detail. Although the access token each station receives does contain the reviewer's name and email address, neither is ever transmitted.
The engineering team cannot tell from a report who submitted it, and the feature provides no channel through which anyone at UiPath could contact that person. Reports are not answered individually.
How long reports are kept
Reports are subject to the same retention policy as all other Document Understanding diagnostic telemetry. For more information about how UiPath handles data privacy for Document Understanding, see Legal information.
Availability and turning the feature off
The button's availability is controlled by UiPath through a server-side setting evaluated for each organization and tenant, so it does not appear for every organization. The two stations are controlled separately, so the button can be available in one and not the other.
There is no self-service way to turn it off. No setting in Action Center, Orchestrator, or either station hides the button, and it cannot be disabled per user, per folder, or per tenant by an administrator. Changing its availability for an organization requires a request to UiPath.
Informations associées
- Finding the button
- First visit
- What the dialog contains
- Describing the problem
- Sending the results and taxonomy
- Trying a previous version
- What data is sent
- Station de validation
- Station de classification
- Ce qui n'est jamais collecté
- Examples of the data that is sent
- Validation Station structures
- Classification Station structures
- How the data reaches UiPath
- Who can access this data
- What identifies a report
- How long reports are kept
- Availability and turning the feature off
- Informations associées