Oracle Fusion offers several ways to collect additional information during requisitioning, procurement, and payment. The hard part is choosing a method that appears at the right moment, reaches the right users, supports approvals, and does not create unnecessary friction.
Start with the purpose, not the field
A request to “add a field” is usually the beginning of the design discussion, not the answer. First identify who supplies the information, when it becomes known, what transaction or line it belongs to, whether it must drive routing, and where it needs to appear later.
- Define the decision or obligation. Is the data needed for approval, compliance, reporting, downstream processing, or audit?
- Locate the earliest reliable capture point. Ask whether a requester, buyer, supplier, approver, or Payables user truly knows the answer.
- Choose the narrowest relevant audience. Avoid showing specialized questions on every transaction when they apply only to certain categories, items, forms, or purchasing methods.
- Trace the downstream path. Confirm whether the value must flow from requisition to purchase order, appear in notifications, or remain available for reporting.
- Test the exceptions. Include punchouts, catalogs, noncatalog requests, change orders, multiple lines, integrations, and delegated approvals.
Requisition-stage options
Descriptive flexfields
Best for: Structured attributes at the requisition header or line that may need to flow to the purchase order or participate in routing.
A global DFF appears broadly. A context-sensitive DFF first requires a context selection, then shows fields associated with that choice.
Information templates
Best for: Questions associated with a Smart Form, item, or purchasing category.
Information templates build on flexfield architecture but can target a specific buying experience more precisely than a globally displayed field.
Smart Forms
Best for: Guided noncatalog requests with useful defaults and a reduced set of required inputs.
A Smart Form can give a specialized request a clear name, default important values, and present an information template as part of the experience.
Punchout considerations
Watch for: The request originates on the supplier’s site and returns to Oracle with supplier category data mapped to an internal purchasing category.
An information template generally depends on category association in this path, which can also make the template appear for catalog purchases in the same category.
Approvals and notifications
At the time of the original article, neither DFF nor information-template values appeared in the delivered approval notification automatically. DFF values were available to approval routing and present in the notification data model, making a layout change more direct. Information-template values required an extension to the notification data model before the layout could use them.
That distinction matters. A value captured on the transaction is not automatically visible to an approver, usable as a routing attribute, present in an extract, or available to a downstream integration. Test each required use separately and document any customization.
Purchase-order-stage options
Purchase orders can also use descriptive flexfields, with many of the same presentation and targeting questions. Oracle’s compliance checklist capability adds a richer option built on Supplier Qualification Management concepts.
A compliance checklist uses questionnaire-style components such as questions, branching, acceptable responses, lists of values, and conditional attachments. In the 2024 design described here, a buyer created a checklist and associated it with a purchase order in a one-to-one relationship: one checklist per PO and one PO per checklist. Buyers also needed the appropriate Procurement Agent access.
The principal risk was enforcement. The process depended on the buyer choosing the correct checklist and completing it. Checklist status could be used as an approval attribute, but that downstream control was less helpful than an inline validation that could ensure the correct template was associated before submission.
Compare the available approaches
| Approach | Useful when | Important strengths | Questions to test |
|---|---|---|---|
| Global DFF | The attribute is relevant to nearly every transaction at that level. | Direct, structured capture; may flow downstream; can support routing. | Will it clutter common tasks? Is it required at the correct header or line level? |
| Context-sensitive DFF | Different transaction types need different fields. | Reduces unrelated fields and preserves structured values. | Will users recognize and choose the right context? Can the context be derived or defaulted? |
| Information template | Questions belong to a Smart Form, item, or category. | More targeted requisition experience and reusable question groups. | How does it behave for punchouts and catalogs? Is it visible in approvals and extracts? |
| Smart Form plus template | A specialized noncatalog request needs guidance and defaults. | Clear entry point, fewer inputs, helpful defaults, targeted questions. | Can users bypass the form? Are defaults and category assignments governed? |
| PO compliance checklist | Buyers need branching questions, acceptable responses, or required attachments. | Richer questionnaire behavior using SQM concepts. | Who creates and completes it? Is the correct checklist enforced? Is one-to-one association sufficient? |
A stronger unified model
The original article proposed combining the strongest ideas from information templates and Supplier Qualification Management. Questionnaire branching, selectable values, conditional attachments, and response validation could become more powerful if paired with automatic associations to Smart Forms, items, categories, purchase orders, and punchouts.
A mature model could also consider project attributes, funding sources, or spend against overhead cost centers—for example, when additional documentation is required for a federally funded higher-education purchase. Routing a questionnaire to an internal specialist would reduce the burden on the buyer to gather every answer personally.
Oracle customers have discussed a related enhancement in Customer Connect: Compliance Checklist Ability to Attach to a Requisition or Contract. Access may require an Oracle community account.
Implementation checklist
- Inventory every requested data element and identify its business owner.
- Classify each value by transaction level, capture role, timing, and downstream consumers.
- Confirm whether the field must drive approval routing or only inform the approver.
- Prototype the experience for catalog, punchout, Smart Form, and noncatalog paths.
- Verify notification, reporting, integration, and requisition-to-PO behavior independently.
- Use plain labels, clear instructions, keyboard-accessible controls, visible focus, and error messages that identify the affected field.
- Apply least-privilege security and avoid collecting sensitive data without a defined need, retention rule, and authorized audience.
- Test with representative requesters, buyers, approvers, administrators, and assistive-technology users.
Knowledge check
Choose the right data-capture approach
Choose one answer for each question, then select Check answers.