Enable Native Attachments in Oracle HCM Identification Info: Passport, Visa, and More

Employees add their passports, visas, citizenship records, and driver’s licenses in Identification Info, but out of the box the Redwood forms have no place to upload the document copy itself. There is a native way to add one — no custom component, no code, no separate document upload step. A single Visual Builder page property attaches Oracle’s standard Document Records upload area directly to the form, and it exists for every Identification Info section: Passports, Visas and Permits, Citizenship, and Driver’s Licenses. This walkthrough uses the Passport section as the worked example; the steps are identical for the others.

This guide covers the no-code Visual Builder configuration. For the transaction payload, REST resources, and DOR relationship details behind it, see How Oracle Fusion HCM Creates Passport and DOR Attachments in One Transaction.

What you get

After this configuration, the Passport form in Identification Info shows a Document Records area with a Name field and a native Drag and Drop upload zone. The employee enters passport details and uploads the copy in one step; Oracle creates the passport record and its Document of Record together and stores the file through the standard HCM attachment framework.

Step 1 — Open Identification Info and edit the page

As a user with page-composer access, open Me → Personal Information → Identification Info (or the person’s Identification Info page), then open the Settings and Actions menu and choose Edit Page in Visual Builder Studio.

Visual Builder Studio opens on the identification-info page in your active sandbox.

Step 2 — Open Business Rules → Configure Page Properties

In Visual Builder Studio, open Business Rules for the page. Three options appear: Configure Fields and Regions, Configure Validations, and Configure Page Properties — choose the last one.

Visual Builder Studio Business Rules panel showing the Configure Page Properties option

Step 3 — Set the document type on the Passports section

In Page Properties, expand the Passports section. Alongside the Guided Journey and Add-icon properties you’ll find the one that matters here:

Set Document type at the Passports Section Level = Passport

Pick the document type from the dropdown — it lists the document types defined in your environment.

Page Properties panel with Set Document type at the Passports Section Level set to Passport highlighted in red, and the Citizenship, Driver's Licenses, and Visas and Permits sections highlighted in blue

Note the sections highlighted in blue — Citizenship, Driver’s Licenses, and Visas and Permits each have their own section entry with the same section-level document type property. More on reusing this for those records below.

Step 4 — Save and publish

Save the rule and publish your sandbox/configuration the same way as any other Visual Builder change. The setting is a business rule on the page, so it follows your normal sandbox → publish lifecycle.

Step 5 — Verify the Passport form

Reopen Identification Info and add or edit a passport. The form now shows the native attachment experience below the passport fields: a Document Records heading, a Name field, and the Drag and Drop file area.

Redwood Passport form showing Issuing Country, Number, dates, and the native Document Records section with Name field and Drag and Drop upload area

Step 6 — Verify the stored document

After submitting, open the passport’s Document Records panel. The uploaded file appears as a document record attachment — viewable and downloadable through the standard experience.

Passports Document Records panel listing the uploaded passport file with download and preview actions

If your document records are subject to approval, the passport change shows Pending Approval until the transaction completes — that’s the standard HCM approval flow applying to the combined passport + document record transaction, not an error in the configuration.

The same setting works for visa, citizenship, and driver’s license attachments

This is not a Passport-only feature. The Page Properties panel lists a section for each Identification Info record type — Citizenship, Driver’s Licenses, Passports, and Visas and Permits — and each exposes its own Set Document type at the … Section Level property. To let employees upload a visa or work permit copy, expand Visas and Permits and set its document type; for a citizenship certificate, use the Citizenship section; for a license copy, Driver’s Licenses. Publish once and each configured section gets the same native Document Records area on its form.

One rule of thumb: map each section to its own matching document type rather than reusing one generic type everywhere. The document type drives where the record files under the person’s document records, its security, and any approval routing — a visa stored under a passport document type will confuse both reporting and document type security later.

Oracle 26B: the same setting now covers three Personal Details sections too

Starting with Oracle 26B, this integration is no longer limited to Identification Info. Oracle extended the same Document Records page-property mechanism to three sections under Personal Details: Demographic Info, National Identifiers, and Biographical Info. The setup follows the identical pattern described above — open Business Rules → Configure Page Properties for the relevant page, expand the section, and set its Set Document type at the … Section Level property. We don’t have our own screenshots of the Personal Details pages yet (ours above are all from Identification Info), but the property, the dropdown, and the resulting Document Records + Drag and Drop area behave the same way once configured.

This matters for the same reason the Identification Info version does: it closes the gap between a personal-information update and the evidence behind it. A marital-status change accompanied by a marriage certificate, a national identifier correction, a biographical detail update — the supporting document can now be retained through Document Records instead of existing only as a one-time approval attachment that disappears once the transaction completes.

Five things to know before you turn this on

The setting is simple to configure, but the underlying behavior has some edges worth knowing before employees start relying on it:

Pick the document type carefully, and don’t change it later. Once a section has been using a document type in production, avoid switching it. Records created under the old type can stop showing up in that section once you point the property at a different type — treat the choice as close to permanent.
This is basic attachment retention, not the full Document Records experience. The page-property integration covers “attach a file when you make this update.” If your requirement is more advanced — retention schedules, complex document workflows, document-type-specific validations beyond what the standard framework offers — use the standalone Document Records page directly rather than relying on this shortcut.
Effective-dated sections share attachments across rows. For effective-dated objects (Passports and the other Identification Info sections are the clearest example), an attachment added on one effective-dated row can appear on other effective-dated rows of the same record — and removing it removes it from all of them, not just the row you were editing. Don’t assume per-row isolation.
Approval-time attachments and the retained Document Record are two different things. When approvals are enabled for a transaction, you can end up with two separate attachment regions on the form: the approval-only attachment (visible only during the approval flow, not retained afterward) and the actual Document Record created by this configuration (retained for future reference). Don’t confuse the two when troubleshooting a “missing” file — check which region the user uploaded to.
The Document Records privilege gates the whole region. A user without the Document Records privilege won’t see the upload area at all, even with the page property correctly configured — check role/privilege access before assuming the configuration itself is broken.

Troubleshooting

No Document Records area after publishing — confirm you set the property on the Passports section (not Common Properties), and that you’re testing with the sandbox/publication that contains the rule.
The document type dropdown doesn’t list your type — the document type must exist (Document Types task in Setup and Maintenance) and be visible to the user’s document type security before it can be selected or used.
Upload works but the file isn’t visible to another user — that’s document record security (person security profile / document type access), not the page configuration.

What happens under the hood

The upload area isn’t a widget bolted onto the form — Oracle submits the passport and its Document of Record as one transaction, linking the DOR to the passport record. If you need that level of detail — the seeded GLB_PASSPORT document type, the PER_PASSPORTS/PASSPORT_ID relationship, CallerContext, and the batch payload — the integration deep dive walks through it, and the documentRecords REST API guide covers reading those documents back out through the API.

None of that structure is visible from the page you just configured, which is why we built OPAL — a free offline explorer for the entire Oracle Fusion API surface. Type documentRecords or passports into it and you see every field, q filter, and child resource this configuration writes to, straight from the real spec, without hunting through the docs.

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