Approval and rejection records for approval-routing agents

Prepare, route or pre-screen: what each agent job needs

An approval agent can do three different jobs, and each needs a different slice of the same history. Name the job first: a dataset that is strong for routing can be nearly useless for pre-screening.

These are people's decisions on other people's requests, not the logs agent platforms write when a reviewer approves an agent's proposed action. Vendor guidance for those logs lists agent identity, business context, requested tool, input payload, policy version, reviewer, timestamp and outcome [1], and one support vendor frames its approvals as feedback that improves AI accuracy over time [2]. Only the business history shows how approvers judge real requests at volume. Correction-style records are covered in human override and correction logs.

Where approvals are recorded, and where the reasons go missing

The decision lives in the system that owned the request, while the reason often lives somewhere else. A usable dataset joins the two.

• ERP purchasing. In SAP, requisition approval can run through release strategies. A release code is a two-character ID that lets a person or group release a blocked document, and authorizations control who may use it [3]. The release indicator records the current status, which usually starts as blocked [4].
• Procurement and expense suites. Approval chains, send-backs and policy-violation flags sit in workflow history, often per line item.
• IT service management. Change records carry reviewer comments, approvals and rejections; see SourceX's overview of change approval records.
• Document and contract approval. Review rounds, redlines and sign-offs; see how document approval works and document approval records.
• Email and chat. Many returns for information are a one-line reply ("which budget line?") that never reaches the workflow tool. Ask whether the supplier can link these messages to the request ID.

The public BPI Challenge 2020 logs show a multi-step chain: a university's travel expense claims go to travel administration, then the budget owner, then the supervisor, with one step when those two are the same person and a director in some cases [5]. The domestic declarations file holds 10,500 cases and 56,437 events [6]. Check how its XES attributes encode rejections before relying on it, and treat it as a structural reference, not training volume. See process mining event logs for formats and procure-to-pay and order-to-cash records for the purchasing chain around the procurement approval step.

Outcome labels beyond approve and reject

A binary approved/rejected flag hides most of what an approval agent needs to learn. Ask the supplier to map its statuses to a taxonomy like this one and to report counts per class before you buy.

Vendor guidance describes designs that approve low-risk requests by policy and route only sensitive ones to a person [7], so unflagged auto-approvals teach a model to imitate the rule, not the reviewer. Rejections and returns are the rare classes: specify minimum counts for each instead of a total record count. Blocks and mismatches resolved by investigation belong with exception handling records, and judgments documented with their full inputs with decision records with rationale.

Delegation of authority must ship with the decisions

Without the DoA matrix in force on each decision date, a routing agent learns who happened to approve, not who was required to. Thresholds change with reorganizations, budget cycles and acquisitions, so ask for every version with effective-from and effective-to dates.

In SAP the matrix is configuration: each release criterion is a characteristic linked to a requisition field, and each release strategy assigns values or value intervals to those characteristics [3]. SAP's own example is strategy BA for document type NB above a total value of $10,000 [3], and codes can be required in order: in SAP's example, 01 and 02 must release a requisition before 03 can [4]. Strategies, release codes and code holders exported by date give you routing ground truth; the approval log alone does not.

Also request out-of-office delegations with date ranges, approval limits by role and level, and the governing policies with version dates. Out-of-policy approvals, such as a sign-off above the approver's limit, become useful labels when flagged.

What one approval record should hold

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "request_id": "REQ-48213",
  "request_type": "purchase_requisition",
  "submitted_at": "2025-03-04T15:12:00Z",
  "requester": {"person_key": "p_7f3a", "role": "Field Operations Manager", "cost_center": "CC-410"},
  "category": "IT hardware",
  "quantity": 15,
  "unit_price": 1230.00,
  "amount": {"value": 18450.00, "currency": "USD"},
  "doa_version": "DOA-2025-01",
  "routing_rule_hit": "IT spend 10k-50k: department head, then IT director",
  "steps": [
    {"seq": 1, "approver_key": "p_21c9", "approver_role": "Department Head", "required_by_rule": true,
     "action": "return_for_information", "reason_code": "MISSING_QUOTE",
     "comment": "Second vendor quote required under policy 4.2",
     "opened_at": "2025-03-04T16:40:00Z", "acted_at": "2025-03-05T09:02:00Z"},
    {"seq": 2, "approver_key": "p_21c9", "approver_role": "Department Head", "required_by_rule": true,
     "action": "approve", "reason_code": null,
     "opened_at": "2025-03-06T13:10:00Z", "acted_at": "2025-03-06T13:31:00Z"},
    {"seq": 3, "approver_key": "p_88d0", "approver_role": "IT Director (delegate)", "required_by_rule": true,
     "delegated_from": "p_5b12", "action": "approve_with_change", "change": "quantity 15 -> 12",
     "opened_at": "2025-03-06T14:02:00Z", "acted_at": "2025-03-07T10:15:00Z"}
  ],
  "auto_approved": false,
  "final_outcome": "approved_with_change",
  "downstream": {"po_issued": true, "po_amount": 14760.00, "later_reversed": false}
}

The DoA version and rule hit are routing labels, and the per-step action and reason code are pre-screening labels. The gap between opened_at and acted_at measures review effort, and the downstream block shows whether the decision held.

Signal checks before you buy volume

Very high approval rates and near-instant decisions can mean rubber-stamping, so measure signal on a sample before paying for volume. Vendor guidance on agent approval gates warns that rubber-stamp approvals reduce a control to a formality [1], and historical business approvals have the same failure.

• Outcome mix per approver and DoA tier. An approver who approves nearly everything adds little negative signal; ask for distributions, not averages.
• Dwell time. Time from opening to decision, by decision type. Many systems log only the decision, so ask whether an opened or assigned timestamp exists.
• Reason coverage. The share of rejections and returns with a reason code or substantive comment.
• Resubmission linkage. Whether a returned request links to its resubmission, which shows a preparing agent what fixed it.
• Rule versus human. Whether auto-approvals and system escalations are distinguishable from people's actions.
• Downstream confirmation. Whether later events (PO cancelled, invoice disputed, change rolled back) can be joined; see verifying outcome labels in operational records.

Label noise matters most in evaluation sets. Northcutt et al. estimated an average label error rate of at least 3.3% across the test sets of 10 widely used datasets and showed that such errors can change which model ranks best [8]. For approvals, build evaluation splits from downstream-confirmed cases, hold out by time and DoA version, and report recall on rejections and returns separately. Classification fine-tuning data covers label-noise handling.

Employee identities, vendor terms and regulated decisions

Approval records hold requester and approver identities, remarks about colleagues, vendor prices and sometimes salaries. Decide early which of these the agent needs.

• People. Routing needs roles, levels and limits, not names, so ask for consistent pseudonymous person keys. Under the GDPR, pseudonymised data that can be attributed to a person with separately held information is still personal data [9], which matters if approvers include EU staff. Under the CCPA, data is deidentified only if, among other conditions, the business contractually binds recipients to the definition's requirements [10]; expect those terms in the license.
• Free text. Comments mention leave, health reasons for travel and performance. Ask whether redaction keeps the reason intact.
• Commercial terms. Vendor quotes and negotiated prices may be under the supplier's confidentiality obligations. Ask whether they are masked, bucketed or kept.
• HR approvals. Offer, raise and termination approvals are a separate risk class; decide whether to include them at all.
• Regulated decisions. As of October 2026, Colorado's SB26-189 (signed 14 May 2026) requires developers of automated decision-making technology that materially influences a consequential decision, such as employment, lending or insurance, to give deployers documentation including training data categories, with core duties from 1 January 2027 [11]. A pre-screening agent for credit, hiring or insurance approvals may be in scope; confirm with counsel. Commercial credit memo data covers lending approvals.

When SourceX sources approval records, every dataset goes through rights review, which checks that the business owns or may share the records and that required consents are in place. Names, emails, phone numbers and account numbers are removed or replaced before delivery, the method is recorded, and a sample is checked after processing. No de-identification method is perfect, so keep your own leakage checks.

Approval data request checklist

A strong request names the agent job, the decision classes with minimum counts, and the routing context, then lets the supplier say which systems can produce them.

1. Agent job (prepare, route, pre-screen) and use: training, evaluation or both.
2. Request types: requisitions, expenses, changes, contracts, discounts, access or credit.
3. Decision taxonomy mapped from supplier statuses, with minimum counts for rejections, returns and approvals with changes.
4. DoA matrices and policies by version with effective dates, plus delegations.
5. Per-step fields: approver role and level, required-by-rule flag, action, reason code, comment, opened and acted timestamps with time zone.
6. Links to resubmissions, attachments, related messages and downstream outcomes.
7. Flags for auto-approvals and system escalations.
8. A time span crossing at least one DoA change, so models are tested on unseen rules.
9. Privacy treatment: person keys, comment redaction, vendor masking, exclusions.
10. Format: relational tables (requests, steps, DoA versions, delegations) in CSV or Parquet; XES event logs under IEEE 1849-2023, which superseded the 2016 version [12]; or OCEL 2.0 when one request touches lines, purchase orders and invoices, since it records qualified event-to-object and object-to-object relations [13].
11. Licensed uses; see license terms for agent workflow data and evaluating an agent data sample.

SourceX sources operational datasets, including finance and legal workflow records, from US companies on request rather than from stock, so a request does not guarantee a match. You can describe the approval records your agent needs without naming companies. Other agent data types are mapped in the AI agent training data hub.

Need approval histories with the reasons attached?

Describe the agent job, the request types and the decision classes you need. SourceX looks for US businesses that hold matching approval records, checks the data and the supplier's licensing permissions, and coordinates the license, delivery and payment; nothing is contracted until a supplier agrees. Specify your approval workflow dataset.