Extensibility

ADM runs inside your database. You can query its tables, join to them, and drive it from your own PL/SQL — no integration layer, no API keys, no data leaving the database.

That access comes with a small set of rules. They exist so that you can install patches and upgrades without losing your work, and so we can support the result.

The four ways to extend

	Use it for	Read
PL/SQL APIs	Doing anything ADM does, from your own code: creating folders, uploading, sharing, tagging, searching.	Managing the filesystem from the database · API reference
Hooks	Reacting to an upload or a folder creation, or refusing one.	Hooks
Embed tokens	Showing ADM content inside another application.	Embedding
The data model and views	Reporting, joining ADM data to yours.	Reporting views

Working with the data model

Every table and column carries a comment, so the model is explorable from the database itself:

select table_name
     , comments
  from user_tab_comments
 where table_name like 'ADM_%'
 order by table_name;

Storing an ADM folder_id or document_id in your tables to link the two worlds is supported. A support case with a contract, a claim with its evidence.

How to reference ADM ids from your own tables

If you add a foreign key to an ADM table, it must be on delete cascade or on delete set null. A restricting constraint makes ADM’s own delete fail, which turns an ordinary user action into an error nobody can clear. Ids are up to 32 decimal digits — declare your columns number, never integer.

Reading and writing

Read freely: the tables, and especially the reporting views, are yours to query.

Write only through the documented APIs. A direct insert into adm_documents produces a document with no version, no audit entry, no metadata, no hook fired, and no storage policy applied — a row that looks like a document and behaves like nothing.

ADM packages never commit or roll back. The transaction is yours, which means several operations compose into one atomic unit — and it also means nothing is persisted until you commit.

Rules for staying supported and upgradeable

Follow these and an upgrade is uneventful. Break them and it silently reverts your work — see Upgrading.

• Do not modify ADM database objects — tables, views, packages, triggers. install.sql replaces them.
• Do not modify the APEX application. A re-import replaces it, page by page.
• Do not add restricting foreign keys to ADM tables. on delete cascade or on delete set null only.
• Do not insert into adm_ tables directly. Use the APIs.
• Do not call anything marked @private in the API reference. Those signatures change between releases without notice; the public ones do not.
• Raise your own errors in -20700 .. -20999. Every other 20xxx range belongs to ADM, the AI Pack, or a bundled library. See Error handling.

If you need something ADM will not let you do

Tell us rather than patching around it. A missing parameter or a needed hook event is a small change on our side and a permanent maintenance burden on yours.

Also refer to

• Hooks
• Managing the filesystem from the database
• The security model — your code needs a context before it can do anything
• Error handling
• Upgrading