Document management and the security-domain boundary

The pattern: one store, one generic link table

Instead of a document store per record type, use one document store plus a generic link table that associates a document with any record type:

Column	Purpose
documentId	the Appian document
relatedRecordType	which record type this attaches to
relatedRecordId	which instance

Why it wins: a new record type needs no new store, no new folder tree and no new schema — it inserts rows into a table that already exists. Attachment becomes a data concern instead of a structural one.

The rule that carries the most weight

Record-level security is only a query filter. It is NOT document security.

A user who is filtered out of a record can still reach the document if the document's folder permits it. The record filter never touched the file.

Therefore: folder ACLs must be set per security domain, and that is mandatory, not an optimization. Group documents into folders that mirror who is allowed to see them, and set the ACL on the folder. The link table says what relates to what; the folder ACL says who may open it. Those are two different questions, and only one of them is enforced by the record.

Why this is a Lead-level decision rather than an implementation detail

It is not an implementation detail — it is a design-authority call. It decides the security model before the first object is built, and getting it wrong is not refactorable once documents exist and permissions have been inherited.

The test question for any Appian security design: "if the record query were removed entirely, what would still stop this user reaching this data?" If the answer is "nothing," the security is cosmetic.