Skip to content

Feature overview

Every feature ADM ships gets a paragraph here and a link to the guide that explains how to use it. If you are evaluating ADM, read this top to bottom. If you are looking for one thing, use the sidebar or the search box.

Everything below is available two ways: through the APEX application, and through a documented PL/SQL API you can call from your own code. The API reference lists every package.

ADM stores documents in a folder hierarchy. It has one root, under which every user and every group gets their own home folder, and folders nest to any depth. Ownership follows location: a file in your home folder is yours, and nobody else sees it until you share it. Each user folder also has a system-managed trash folder, so deleting is recoverable rather than final.

→ The filesystem

Upload single or multiple files, rename, move between folders, send to trash and restore from it. Maximum file size and the other upload limits are settings, not hard-coded numbers.

→ Working with documents

Uploading a file that already exists adds a version rather than overwriting. The version history of a document shows who uploaded each one and when; you can preview an old version, open two versions side by side, restore one as the current version, or delete a single version. Each version carries a checksum, which is what makes storage verification possible.

→ Working with documents — versions

Package a document, a selection, or a whole folder subtree into a zip file, and unzip an uploaded archive back into a folder structure. Both directions are available as PL/SQL, so a nightly export is a job, not a manual click-through.

→ Zipping and unzipping

Search matches on filename and on file content. Content search uses Oracle Text, which means the text inside PDFs, Office documents and the other formats Oracle’s filter supports is searchable — once the file has been through the indexing queue.

Tags in ADM are key/value pairs, not free-text labels: Department = Finance, Contract type = NDA. The faceted search interface works on those pairs: pick a tag, see the values that exist, narrow down. Tag groups let you offer a controlled vocabulary rather than whatever users type.

→ Search and taxonomy

Every user has one of three roles — ADMIN, CONTRIBUTOR, VIEWER — and that role is the ceiling on what they can do anywhere. Beneath it, access to an individual file or folder comes from ownership, group membership, or an explicit share.

→ The security model

Share a document or a folder with a user or a group, at view or edit level. A folder share carries down the subtree. Shares can be revoked individually, or all at once for a given user.

For recipients who do not have an ADM account, create a link share: a URL that grants access to one document, optionally protected by a password and an expiry date.

→ Sharing

Embed tokens open a scoped, expiring window onto one document or one folder, which another APEX application can render inline. The other application does not need to authenticate against ADM — the token and its checksummed parameters are the security boundary.

→ Embedding ADM into other applications

Documents are previewed in the browser: PDFs, images, HTML and Markdown, and .msg/.eml email files. Office documents can be opened for editing and saved straight back into ADM as a new version, converted to PDF, and images can be cropped and rotated in place. Comments (annotations) can be attached to any document or folder.

→ Editing and converting documents

Every meaningful action — upload, download, share, rename, delete, permission change — is written to the audit log with the user and timestamp. It is browsable per file and per folder in the admin section, and queryable through adm_report_audit_log_v.

→ Administration

A retention policy sets a date on which a document is deleted automatically, and blocks manual deletion until then. A legal hold blocks deletion indefinitely, until someone with the rights lifts it. Both are set through the API, and both are enforced by the product rather than by policy.

→ Records management

The admin section covers users, groups, a root view onto the whole filesystem, the audit log, duplicate-file detection, embed tokens, hooks, settings, and the job log.

→ Administration · Users and groups

Around thirty settings control storage, upload limits, indexing, retention of trashed files, checksum verification and the external services ADM talks to.

→ Settings reference

File content lives either in a database BLOB or in OCI Object Storage — a setting, not a build choice. Switching moves existing content in the background, in batches, with checksum verification on both sides. Application code never sees the difference, because it goes through adm_storage_api.

→ Storage and versioning · Object storage setup

A daily job empties trash past its retention window, deletes files whose retention date has passed, removes expired embed tokens, processes storage migrations and pending deletions, works the full-text indexing queue, re-verifies checksums and backfills file metadata. Everything it does is written to the job log.

→ Jobs and maintenance

Every feature in the app is a package call. Create folder trees, upload documents, share them, tag them and search them from your own PL/SQL, under the identity of whichever user you choose.

→ Managing the filesystem from the database · API reference

Register your own PL/SQL against product events — a new file uploaded, a new version added, a folder created — to trigger downstream processing, enforce a naming policy, or reject an upload outright.

→ Hooks

Every error ADM raises has a stable number, a named exception and a category, so your code can catch the specific case it cares about instead of parsing messages.

→ Error handling

All tables and columns carry comments. Query them, join to them, and store ADM folder or document IDs in your own tables — within the rules that keep an upgrade safe.

→ Extensibility · Reporting views

The AI Pack is installed separately, on top of the base product.

  • RAG collections — point a collection at folders or documents and it keeps itself in sync: extract text, chunk it, embed it, store the vectors in Qdrant.
  • Semantic search and generated answers — search chunks, assemble sources, and generate an answer with citations, with optional query rewriting and hybrid keyword + vector search.
  • Agent tools — expose ADM’s search and retrieval to your own LLM agent as callable tools.
  • LLM text extraction — use a vision model for documents that Oracle’s text filter cannot read well, such as scanned PDFs.

→ RAG configurations