How Oracle Fusion HCM Creates Passport and DOR Attachments in One Transaction

When an employee saves a passport with an attached copy in Oracle Fusion HCM Redwood, one transaction creates two records: the passport in Identification Info and a Document of Record (DOR) holding the file. This post is the technical deep dive into how that transaction is put together — the seeded document type, the relationship metadata that links the DOR to the passport, and the batch payload Visual Builder submits. It comes from a working implementation; Oracle’s docs describe the pieces individually, but not how they wire together.

Looking only to enable the native attachment area from Visual Builder page properties? See How to Enable Native Passport Attachments in Oracle Fusion HCM Redwood — the no-code configuration guide. This post is for when you need to understand or extend what that setting does.

The happy path: expose the seeded Document Records fragment on the Passport page, create a GLB_PASSPORT DOR automatically, and let the user upload the passport attachment once through Oracle’s native attachment component. If you’re working with document records through the REST API directly rather than the Redwood UI, our documentRecords REST API guide covers that end of the same flow.

The same architecture applies when extending Identification Info for national identifiers, visas, work permits, citizenship records, driver’s licenses, and other employee identification documents — more on that below.

What the solution delivers

The completed Passport experience allows the user to:

1. Add or update passport information from Identification Info.
2. Upload the passport image or PDF in the same Redwood page.
3. Create the Passport record and its related Document of Record together.
4. Store the file using Oracle’s native DOR attachment framework.
5. View the uploaded file later from the related Document Record.

No separate custom document table, external file store, or standalone upload service is required.

Oracle components used

Component	Purpose
Identification Info Passport fragment	Captures Passport number, type, issuing country, dates, authority, and flexfields
Document Records public UI fragment	Provides the native DOR details and attachment component
GLB_PASSPORT	Seeded Passport system document type
PER_PASSPORTS	Related Oracle HCM Passport object
PASSPORT_ID	Column used to relate the DOR to the Passport record
Visual Builder Studio	Extends the Redwood Passport page
HCM transaction context	Submits Passport and DOR data in one transaction

The seeded Document Records fragment is referenced through:

/vbcs/hcm/document-records-public-ui/fragments/document-records

Key relationship values

The Document Record must be configured as a Passport DOR and related to the Passport business object:

{
  "SystemDocumentType": "GLB_PASSPORT",
  "RelatedObjectName": "PER_PASSPORTS",
  "RelatedObjectIdColumn": "PASSPORT_ID"
}

These values tell Oracle Fusion HCM that the uploaded Document of Record belongs to a Passport created from the Identification Info page.

Visual Builder implementation

Create an extension for the Redwood Identification Info Passport page in Visual Builder Studio.

Add the seeded Document Records public UI fragment to the Passport experience and pass the Passport-specific DOR configuration into it. The DOR fragment should build a payload similar to:

{
  "SystemDocumentType": "GLB_PASSPORT",
  "PersonId": "300000000000000",
  "RelatedObjectIdColumn": "PASSPORT_ID",
  "RelatedObjectName": "PER_PASSPORTS",
  "DocumentName": "Passport Copy",
  "attachments": []
}

The user then uploads the file through the native attachment area. Oracle’s attachment framework adds the attachment metadata to the DOR payload automatically.

A completed attachment entry normally includes values such as:

{
  "AsyncTrackerId": "generated-by-oracle",
  "CategoryName": "MISC",
  "ContentRepositoryFileShared": "false",
  "DatatypeCode": "FILE",
  "FileName": "passport-copy.pdf",
  "Title": "passport-copy.pdf",
  "UploadedFileName": "passport-copy.pdf"
}

Do not generate the AsyncTrackerId yourself. It is produced by Oracle’s native attachment upload framework when the employee selects the file.

Register the DOR fragment in the transaction context

The Passport transaction must declare the Document Records fragment in TransactionContextPayloadSequence:

{
  "Name": "oracle_hcm_documentrecordspublicUI___document-records",
  "Sequence": 1,
  "VBResourceName": "/vbcs/hcm/document-records-public-ui/fragments/document-records"
}

The DOR payload is supplied through TransactionContextPayloadAttributes:

{
  "Name": "oracle_hcm_documentrecordspublicUI___document-records",
  "Value": "[{\"payload\":{\"SystemDocumentType\":\"GLB_PASSPORT\",\"PersonId\":\"300000000000000\",\"RelatedObjectIdColumn\":\"PASSPORT_ID\",\"RelatedObjectName\":\"PER_PASSPORTS\",\"attachments\":[{\"AsyncTrackerId\":\"generated-by-oracle\",\"CategoryName\":\"MISC\",\"ContentRepositoryFileShared\":\"false\",\"DatatypeCode\":\"FILE\",\"FileName\":\"passport-copy.pdf\",\"Title\":\"passport-copy.pdf\",\"UploadedFileName\":\"passport-copy.pdf\"}],\"DocumentName\":\"Passport Copy\"},\"id\":\"documentRecords--1\",\"path\":\"/documentRecords\",\"operation\":\"create\"}]"
}

This lets Oracle process the Passport record and the related Passport DOR in the same HCM transaction.

Passport create payload

The Passport itself is created through the standard personPassports resource:

{
  "id": "passport",
  "path": "/personPassports",
  "operation": "create",
  "payload": {
    "PersonId": "300000000000000",
    "IssuingCountry": "AE",
    "PassportType": "D",
    "PassportNumber": "P1234567",
    "IssuingAuthority": "Passport Authority",
    "IssueDate": "2026-07-01",
    "ExpirationDate": "2031-07-01",
    "IssuingLocation": "Abu Dhabi",
    "CallerContext": "DOR"
  }
}

The important value is:

{
  "CallerContext": "DOR"
}

It identifies that the Passport operation is being submitted together with a related Document of Record.

DOR create payload

The Document Record is created in the same batch:

{
  "id": "documentRecords--1",
  "path": "/documentRecords",
  "operation": "create",
  "payload": {
    "SystemDocumentType": "GLB_PASSPORT",
    "PersonId": "300000000000000",
    "RelatedObjectIdColumn": "PASSPORT_ID",
    "RelatedObjectName": "PER_PASSPORTS",
    "DocumentName": "Passport Copy",
    "attachments": [
      {
        "AsyncTrackerId": "generated-by-oracle",
        "CategoryName": "MISC",
        "ContentRepositoryFileShared": "false",
        "DatatypeCode": "FILE",
        "FileName": "passport-copy.pdf",
        "Title": "passport-copy.pdf",
        "UploadedFileName": "passport-copy.pdf"
      }
    ]
  }
}

Oracle creates the Passport, creates the DOR, and links the DOR to the resulting Passport ID through PER_PASSPORTS.PASSPORT_ID.

Why use the native DOR attachment component

Using the seeded Document Records attachment experience provides several advantages:

• The upload follows Oracle’s standard HCM attachment behavior.
• Files are stored through the Fusion Content Repository.
• The DOR remains related to the employee and Passport record.
• Existing DOR security, categories, document types, and retention behavior can be reused.
• The UI remains consistent with other Redwood employee document experiences.
• The same design can be extended to other identification document flows.

This is preferable to creating a custom file upload that stores only a URL, Base64 value, or unrelated attachment record.

How this maps to the REST API

The Redwood transaction above is the UI face of resources you can also reach directly. In the real Oracle HCM spec:

• Passports live as a child of workers: GET/POST /workers/{workersUniqID}/child/passports. The create body has exactly the fields used in the Visual Builder payload above — PassportNumber, PassportType, IssuingCountry, IssuingAuthority, IssueDate, ExpirationDate, IssuingLocation, plus Profession and a passportsDDF flexfield child. The response adds PassportId — the value the DOR relationship binds to. Browse the full workers surface (307 q fields, 20 children) on our workers reference page.
• documentRecords is a 38-path resource with 39 queryable fields, its own attachments child, and a FileContents enclosure for downloading the stored file — the documentRecords REST API guide walks through create, upload, and download with working requests.

So after this extension goes live, an integration can still read the same data the Redwood page created: the passport via the workers child resource, and the passport copy via the document record’s attachment enclosure. One data model, two front doors.

Applying the pattern to other Identification Info records

The same design reuses cleanly for the other identification and personal information records in Oracle Fusion HCM — national identifiers, visas and work permits, citizenship records, driver’s licenses, and residence documents. Each follows the identical shape: seeded document type, related object, relationship column, and the same Document Records fragment in the transaction context.

Do not reuse GLB_PASSPORT, PER_PASSPORTS, or PASSPORT_ID blindly for another record type. Each identification record must use its own supported system document type and relationship metadata — confirm the seeded document type exists in your environment (Document Types task) before wiring the fragment, because a mismatched RelatedObjectName/RelatedObjectIdColumn pair fails at submit, not at design time.

Validation checklist

Before publishing the Visual Builder extension, confirm:

• The native Document Records fragment appears on the Passport page.
• The user can upload PDF and image files.
• The DOR payload contains SystemDocumentType: GLB_PASSPORT.
• The payload contains RelatedObjectName: PER_PASSPORTS.
• The payload contains RelatedObjectIdColumn: PASSPORT_ID.
• The Passport payload contains CallerContext: DOR.
• The uploaded attachment contains an Oracle-generated AsyncTrackerId.
• The Passport and DOR are created in the same transaction.
• The DOR is linked to the created Passport.
• The attachment can be opened from the Document Record after completion.

Common implementation mistakes

• Building a separate custom attachment component: this bypasses seeded DOR behavior and creates additional storage and security work.
• Omitting CallerContext: DOR: the Passport operation may no longer behave as a Passport-plus-DOR transaction.
• Using the wrong related object: Passport DORs must use PER_PASSPORTS and PASSPORT_ID.
• Creating the DOR without the transaction payload sequence: the embedded fragment payload may not participate in the final submit.
• Generating an attachment ID manually: allow Oracle’s attachment component to produce and manage its upload tracker.
• Using only a filename or URL: a native attachment must include the Oracle-generated upload reference.

Final result

The final Redwood page gives employees one complete Passport experience:

Passport details
        +
Native Document of Record
        +
Native Oracle attachment upload
        ↓
One Passport transaction

The Passport remains the primary Identification Info record, while the related GLB_PASSPORT Document of Record stores the employee’s passport copy using Oracle’s native attachment framework. Every field name and resource path above comes from the real Oracle HCM spec — the fastest way to verify them against your own build is OPAL, our free offline explorer for the full HCM and FSCM endpoint surface: every q field, finder, and child resource, searchable in under a second, starting with the endpoint reference.

---

This post is part of our complete Oracle HCM API guide — auth, base URLs, q filters, finders, and the key endpoints in one place.