Skip to content

Access and Folder Administration

Use this page to organize document areas and diagnose the difference between folder visibility and document access. Changes apply to the selected domain and affected objects; changing a shared security profile can affect several objects.

Prepare the Collection

  1. Identify reader, editor, and administrator groups and the business owner of the collection.
  2. Use New Folder under the intended parent and select the document folder type. Creating a child requires Write on the parent; creating a root folder requires domain administrative authority.
  3. Give the folder a business-oriented name and review its Permissions.
  4. Configure document permissions or the selected security profile separately.
  5. Publish a test document and verify folder navigation, document opening, editing, and deletion with separate test identities. Test both an allowed and a denied reader.

Record the previous rules before editing. To roll back access changes, restore those rules and recheck with the affected accounts. These changes do not require an application restart.

Example: Contract Collection

Use this fictional setup in a test domain before applying its pattern to a real collection. It assumes authority to manage the relevant domain groups, security profiles, and folders. Review Edit Groups and Edit Domain for those administration surfaces.

Setting Example and responsibility
Document folder Documentation → Contracts; administrator prepares the document folder and its ACL.
Content type Contract; developer publishes ContractProfile with Number and EffectiveDate.
Document security profile Contract Access; administrator defines the document access rules.
Reader group Contract Readers; intended users can read the folder and published documents.
Editor group Contract Editors; intended users have the document-writing feature and the required folder/document Read and Write permissions.
Administrative operations Grant folder Security, Delete, or other administrative permissions separately where required.
  1. Agree the reader and editor membership with the collection owner. Keep an unaffected administrative account able to restore the previous access rules.
  2. Create the document folder and review folder access for both groups. Editors need folder Write for Add Document; readers need a way to navigate to and read the collection.
  3. Define the Contract Access security profile with the intended document Read/Write rules for those groups. Do not infer document access from the folder ACL or from the Contract content type.
  4. Coordinate with the developer to use Contract Access when publishing scripted records. For manually registered documents, have the responsible editor review that profile before saving; creating a folder does not automatically assign this profile to its documents.
  5. Use Sample contract, number EXAMPLE-001, effective date 2026-01-01, and files contract.txt and schedule.txt for the acceptance check. Confirm the reader can open it, the editor can create a revision, and an excluded account cannot read it. Do not grant All just to make a failed check pass.
  6. Create a revision with effective date 2026-02-01 and verify the previous published revision remains readable only by the intended audience. Profile fields are business information; access continues to be governed by the ACL.

Record the resulting rules and restore the previous rules if access differs from the approved design. For the same scenario from other roles, see profile design and document registration.

Folder ACL and Document ACL Are Separate

A folder without its own ACL uses the nearest ancestor folder ACL. If no ancestor ACL exists, folder checks allow reading and require domain administrative authority for operations above read. Folder listing can include objects for users with other applicable folder permissions, so visibility alone is not proof of document read access.

Documents have their own ACL. A new document's runtime ACL defaults to the domain's default security profile; a new version copies the previous version's ACL. The ACL can refer to a security profile through InheritFrom and can include explicit entries. Do not assume that a document inherits the ACL of whichever folder displays it, or that selecting a content type grants access to its documents.

ACL entries identify a user, unit, position, or group, an allow/deny type, permissions, and optional Begins At and Expires At dates. Inactive date ranges are ignored. A matching active deny for a requested permission rejects that permission check. Include inherited profile entries and all group memberships when investigating effective access.

Operation and Permission Reference

This table describes the authenticated document UI/RPC paths and object-level checks. Feature/scope checks and object checks are separate. It is not a permission model for trusted server scripts.

Operation Feature or scope Relevant object check or behavior
Browse a folder Folder navigation/read capabilities Effective folder ACL controls folder navigation; document ACL controls returned document rows.
Open a document or list published versions document_read Document Read; History is filtered to published versions.
Create a first document document_write Add Document in the folder UI requires folder Write. No existing document ACL exists for the first record; set and verify the resulting ACL.
Create a version of an existing document document_write Write on the latest version used as the source.
Save an existing document through the UI document_write Read to load and Write to save the existing document; Save publishes it.
Change document ACL in the document form document_write Uses the document save path and its Write check; do not assume a separate Security check here.
Delete a document version document_write Delete on the version. The UI shows Delete using its Write-based editing check, so a visible command can still be denied by the server.
Rename a folder or create a child Folder administration capabilities Write on the folder or parent respectively.
Read/change folder ACL Folder administration capabilities Security on the folder.
Delete a folder Folder administration capabilities Delete on the folder; child folders or contained processes block deletion.
Permanently purge a version No purge button in the standard document screen Developer/backend operation; a user-context backend call requires Delete.

All includes the generic permission flags. Execute does not substitute for Write, Delete, or Security. The process-design permission matrix describes processes, not document records.

Trusted script context

Server-side $Documents scripts run within the current tenant without user ACL checks. ListDocuments can explicitly apply a supplied identity. Review script authorization before exposing document operations through a workflow or custom integration.

Publish in Multiple Folders

Publication can associate the same document family with several folders. Each folder lists the latest published version subject to the reader's document permissions. Folder membership belongs to the family, rather than an independent copy of each version. Unpublishing through automation changes a version to Draft and removes the requested folder associations; those associations affect the family's presence in the folders.

Use folder permissions to manage navigation, document permissions for record access, and a new version for a controlled content revision. Hiding a folder is not equivalent to revoking access to every document in it.

Delete Carefully

Folder deletion is not a document purge procedure. Before removing a document folder, inventory its documents and other folder associations, provide another access path where needed, and preserve recovery copies. The folder deletion check rejects child folders and processes; it must not be interpreted as a guarantee that no document associations exist.

Document Delete marks one version as deleted and preserves its profile and files. Purge permanently removes that version and its attached file records. Other versions remain. Purge is not a promise of immediate removal from backups or external repository replicas; apply the deployment's recovery and data-removal procedures separately.