Ask ten Oracle EBS users what ADI stands for and you’ll get five different answers, most of them half-right. The tool itself is simple enough: it lets you build data in Excel and push it into Oracle instead of typing it into a form field by field. What trips people up is that Oracle has shipped three versions of this idea over the years — ADI, Web ADI, and ADE — and the documentation rarely bothers to separate them clearly. This guide does that, then walks through how the tool actually works, when it’s worth setting up, and what to do when it stops cooperating.
What Applications Desktop Integrator Actually Does
Applications Desktop Integrator is Oracle’s bridge between desktop office tools — primarily Excel, occasionally Word and Project — and Oracle E-Business Suite. Instead of entering data into EBS forms one field at a time, you download a formatted spreadsheet, fill it out offline or online, and upload it back. Oracle validates each row against the underlying business logic and reports success or failure per record.
Finance and HR teams already build most of their data in spreadsheets before it ever touches Oracle. ADI just lets them keep doing that, while still writing through Oracle’s supported APIs instead of a manual SQL update someone will regret later.
Two things separate it from a plain import tool. First, the business logic runs on upload — ADI calls the same validation and posting logic the EBS forms use, so a bad row comes back with a real error message rather than failing silently. Second, layouts are configurable per role. A GL accountant’s journal template and an HR analyst’s salary upload template can look nothing alike, and an administrator controls exactly which fields each group sees.
Who Should Use Web ADI — and Who Shouldn’t
Use it if:
- You’re on EBS 12.1 or 12.2 and staying there for at least the next 12–24 months
- Your team already builds data in Excel before keying it into Oracle by hand
- Upload volume is high enough that form-based entry has become a bottleneck — month-end journals, bulk HR updates, batch invoices
- You have PL/SQL support available to build a wrapper procedure if the seeded integrators don’t cover your case
Think twice, or skip it, if:
- You’re migrating to Oracle Fusion Cloud within the next few months. Anything built in Web ADI now gets rebuilt as FBDI or ADFdi later, so the investment has a short shelf life.
- The data volume is genuinely small — a handful of rows a month doesn’t justify the setup cost of a custom integrator. Just use the form.
- Nobody can maintain the wrapper procedure. A custom integrator without solid validation logic is worse than no integrator at all, because it inserts bad data faster than a person would.
- End users don’t have local admin rights to adjust Excel’s Trust Center settings. Without that access, they can’t clear the macro-security errors covered further down, and IT ends up configuring every machine by hand anyway.
ADI vs Web ADI vs ADE
Here’s the distinction most explanations skip:
| Applications Desktop Integrator (ADI) | Web ADI | Application Data Exchange (ADE) | |
|---|---|---|---|
| Installation | Installed locally on each user’s PC | No install — runs through the browser, processing happens server-side | Installed locally, older client-server model |
| Typical era | Oracle 11i and earlier | 11i onward, still active in most current EBS installs | Predates Web ADI, largely superseded |
| Access point | Desktop application launched separately | Export Data icon inside EBS self-service forms | Toolbar icon inside HRMS forms (profile-dependent) |
| Maintenance | Requires patching on every client machine | Centrally maintained on the server | Requires patching on every client machine |
| Current relevance | Legacy — rarely deployed in new setups | Standard for EBS 12.x and later | Mostly retired in favor of Web ADI |
If your organization runs EBS 12.1 or 12.2, what you’re using day to day is almost certainly Web ADI, not the older desktop-installed version. According to Oracle’s HRMS configuration documentation, the HR: Enable Web ADI Integration profile option decides whether a form’s Export Data icon launches Web ADI or falls back to ADE. If you’re troubleshooting and unsure which tool you’re even looking at, check that profile setting before anything else.
[INTERNAL LINK: ADI vs Web ADI vs ADE — Full Comparison]
How Web ADI Works, Step by Step
- Confirm the responsibility
A responsibility with Desktop Integration access needs to exist — either the standard “Desktop Integration Manager” responsibility or a custom one. - Define the interface
This points to a staging table, a sequence, and a PL/SQL wrapper procedure that validates and inserts the data. It’s the backend contract Web ADI talks to. - Design the layout
Choose which columns appear, in what order, at what width, and whether a field belongs in the document header (“context”) or in each row (“line”). - Attach an uploader
Usually built from a standard template, this controls how the upload button behaves. - Generate the document
A user creates a document through Desktop Integration Manager, producing a macro-enabled Excel file (.xlsm) that matches the layout. - Fill it in and upload.
Clicking Upload from the Oracle Add-In sends each row through the wrapper procedure, which validates it, inserts it into the staging table, and returns a message. - Review the results
Successful rows are marked; failed rows show the specific error the procedure returned, so a user can fix just those rows and re-upload.
Step 7 is where a custom integrator earns its keep over a seeded one — you decide exactly what gets validated and exactly what message a user sees when something’s wrong.
A Realistic Scenario: Month-End GL Journal Upload
A GL accountant needs to post 300 adjusting journal entries before close. Entering those one at a time through the standard Enter Journals form would eat most of a day and invite transcription mistakes along the way.
With a Web ADI journal integrator, she creates a document and gets an Excel template with columns for account combination, debit, credit, and description — then pastes in data from a source spreadsheet she was already maintaining. On upload, Web ADI checks each row against the chart of accounts and journal posting rules. Say row 47 references an invalid account combination: that row gets flagged with the specific error while the other 299 post successfully. She fixes row 47 and re-uploads just that one correction, not the whole batch.
That’s the scenario where Web ADI earns its keep — high volume, meaningful validation, and errors caught per row instead of discovering one bad journal after the entire batch has already failed.
Where Web ADI Actually Gets Used
- General Ledger — journal entry uploads and budget loads, especially during month-end close when volume is high and manual entry isn’t realistic.
- Human Resources — mass updates to person records, assignments, and salary data through HRMS self-service forms.
- Receivables — bulk customer account updates, such as tax registration numbers or credit terms, using a custom integrator built against a staging table.
- Payables — invoice batch creation where line-item volume makes form-based entry impractical.
Any process where someone is already building the data in Excel and manually re-keying it into EBS is a candidate for an integrator.
Decision Framework: Seeded Integrator, Custom Integrator, or Skip It
Work through this in order before building anything:
- Does Oracle already ship an integrator for this?
Standard GL journal and budget integrators, plus several HR upload templates, come seeded with EBS. Check the Create Document list in Desktop Integration Manager first — this resolves a surprising number of requests on its own. - Is the process high-volume and recurring?
A one-off task rarely justifies the setup cost of a custom integrator. Do it manually, or ask IT for a one-time SQL load instead. - Do you have PL/SQL support to build and maintain the wrapper procedure?
If not, stop here. A custom integrator without a properly tested wrapper is a data-integrity risk, not a productivity win. - Is a Fusion Cloud migration on the roadmap within the year?
If so, weigh building custom EBS-only tooling now against waiting and building the FBDI/ADFdi equivalent post-migration. - Only once all four hold up does it make sense to move into interface definition and layout design.
Setting It Up: What Needs to Be Configured
Most Web ADI problems trace back to configuration, not the tool itself. Four things need to be in place before creating or using an integrator.
Macro settings. If your organization uses digitally signed macros, set the profile option BNE Enable Digital Signature to Yes, then configure Excel and Word to disable all macros except signed ones (Trust Center → Macro Settings). If you’re not using signed macros, disable all macros with notification instead.
OOXML standard. Set BNE: Enable OOXML Standard and FRM: Enable OOXML Standard to Yes on a modern Excel format. Without OOXML, you’ll need to manually enable “Trust access to the VBA project object model” in Excel and Word instead — skip this step and you’ll run straight into the two most common Web ADI errors around:
- Excel:
Run-time error 1004: Method 'VBProject' of object '_Workbook' failed - Word:
Run-time error 6068: Programmatic access to Visual Basic Project is not trusted
Protected View and trusted locations. Add your download folder to Trusted Locations, or disable Protected View for files stored there. Skip this and Excel opens ADI-generated files in a locked-down state that blocks the macros the upload depends on.
Legacy browser settings (older EBS versions only). Versions below 11i.BNE.D on Internet Explorer need File Download and script-based status bar updates enabled, plus ActiveX controls allowed, for the upload dialog to work at all.
Get these four right once, at the responsibility or profile level, and most “it just doesn’t work” tickets never get opened in the first place.
Common Mistakes to Avoid
- Fixing macro security one machine at a time. It doesn’t scale. Push the profile options and, where possible, the Office deployment settings centrally so every user starts configured the same way.
- Skipping “Retrieve Error Information” on the interface definition. Without it, users get a generic Oracle error instead of the specific message your wrapper procedure returns, turning every failed upload into a support ticket instead of a self-service fix.
- Forgetting “Display in Create Document Page.” A well-built integrator nobody can find in the document list is an entirely avoidable dead end.
- Leaving
WHEN OTHERSexceptions unhandled in the wrapper procedure. An unhandled exception surfaces as a raw Oracle error instead of something a user can act on — always trap it and return a readable message. - Treating a custom integrator as finished once it’s live. Chart of account changes, new validation rules, or org restructures can quietly break its logic. Revisit it when the business rules it checks against change.
Common Errors and What They Mean
| Error | Root Cause | Fix |
|---|---|---|
Run-time error 1004: Method 'VBProject' of object '_Workbook' failed | VBA project access not trusted, or OOXML profile not enabled | Enable “Trust access to VBA project object model” or set OOXML profile options |
Run-time error 6068 (Word) | Same as above, Word-specific | Same fix, applied in Word’s Trust Center |
| Upload button does nothing / silent failure | Macros disabled entirely, or file opened in Protected View | Add folder to Trusted Locations; check macro security level |
| Integrator not visible on Create Document page | “Display in Create Document Page” checkbox not enabled during setup | Re-open the integrator definition and enable it |
| Row uploads with a generic Oracle error instead of your custom message | “Retrieve Error Information” not checked on the interface definition | Enable it so the wrapper procedure’s message displays per row |
| Export Data icon opens ADE instead of Web ADI | HR: Enable Web ADI Integration profile set to No | Set the profile to Yes at site level |
Nearly every row in that table is a configuration issue, not a defect in Web ADI itself. The tool is stable; the failure points sit in Excel trust settings and profile options almost every time.
Diagnosing a Web ADI Problem, in Order
- Reproduce it with a seeded integrator first. If a standard Oracle-provided one also fails, the problem is environmental — Excel trust settings or profile options — not specific to your custom build.
- Match the error message to the table above. Most failures map to a small, known set of causes.
- Confirm which tool actually launched. If the Export Data icon opened ADE instead of Web ADI, none of the Web ADI fixes apply. Check the profile option first.
- Isolate client-side from server-side. One affected user usually points to local Excel settings. Everyone affected points to interface, layout, or profile configuration.
- Check the wrapper procedure last. If the document generates and uploads fine but the data doesn’t validate as expected, the issue is in the PL/SQL logic, not in Web ADI’s setup.
Limitations and Warnings
- It’s Excel- and Windows-dependent in practice. Word and Project are technically supported, but the macro-driven upload mechanism ties you to a Windows/Office environment — not a fit for a browser-agnostic or Mac-only workforce.
- A poorly written wrapper procedure is a real risk. Because ADI calls your own PL/SQL logic, gaps in that code — missing validation, unhandled exceptions — insert bad data just as efficiently as good data. Test against edge cases, not just the happy path, before rollout.
- It doesn’t replace data governance. Web ADI enforces whatever validation you build into it. It won’t stop a user from uploading a correctly formatted but wrong account combination unless your wrapper procedure specifically checks for that.
- It has no future on Fusion Cloud. If a migration is confirmed, treat new custom Web ADI development as a temporary investment, not a long-term asset.
Is Web ADI Still Worth Using?
If you’re running EBS 12.1 or 12.2 on-premises, or on Oracle Cloud Infrastructure as a lift-and-shift, Web ADI remains fully supported and in active daily use across organizations ranging from mid-market companies to large enterprises and public-sector bodies.
Fusion Cloud is a different story — it doesn’t use Web ADI at all. Bulk loads run through FBDI (File-Based Data Import), and spreadsheet-style integration within Fusion’s UI runs through ADFdi. If a migration is on your roadmap, any custom Web ADI integrator you build now will eventually need to be rebuilt as an FBDI template — worth factoring in before sinking real effort into a complex custom build.
Keep using Web ADI if EBS is where you’re staying for now. Just treat every new custom integrator as tooling with an EBS-only lifespan, not something you carry forward.
Frequently Asked Questions
Is Applications Desktop Integrator the same as Web ADI?
No. ADI is the older, locally installed desktop version. Web ADI runs in the browser, with processing handled server-side. Most current EBS environments use Web ADI.
Do I need developer access to create a Web ADI integrator?
Only for a custom integrator with its own staging table and PL/SQL wrapper. Using an existing seeded integrator for standard GL or HR uploads just requires the right responsibility and a correctly configured copy of Excel.
Why does my upload succeed in Oracle but not update the Excel sheet with a status?
“Retrieve Error Information” likely wasn’t enabled on the interface definition. Without it, Web ADI can’t display per-row results back in the spreadsheet.
Can I use Web ADI with Word or Project, or is it Excel-only in practice?
Word and Project are both supported, but nearly all real-world usage is Excel-based — most business data (journals, HR records, invoice lines) simply maps more naturally to a spreadsheet.
What replaces Web ADI on Oracle Fusion Cloud?
FBDI for bulk file-based loads, ADFdi for spreadsheet-style integration inside Fusion. Neither is a drop-in replacement; integrators generally need to be rebuilt for the new platform.
Is Web ADI secure enough for financial data?
Web ADI doesn’t bypass EBS security — it runs through the same responsibilities, function security, and validation logic as the forms it replaces. The real question is whether your custom wrapper procedure enforces the same checks a form would, which is why testing that logic matters more than any property of the tool itself.
What’s the most common reason a Web ADI rollout fails across an entire organization, not just for one user?
Inconsistent Excel Trust Center configuration across machines. Pushing macro and trusted-location settings centrally through policy, rather than asking each user to configure their own Excel, is what separates a smooth rollout from a wave of near-identical support tickets.