Structure and Permissions

A file store is more than a path. It has a structure inside it and its own permissions.

Where to find it

Architect Panel → Data:

• File Stores — the stores themselves, and View File Store on a row
• Large Uploads — in-progress and stalled upload sessions
• File Import Routines — watched sources and their mappings

Admin Panel → User Administration:

• User Groups — the groups a store is granted to

Each store has a folder tree

Entries inside a store name their parent, so folders nest. Each entry says whether it is a file or a folder and carries a version number, which is what allows a file to be replaced without losing what came before.

So a store is a small filing system rather than a flat bucket.

Physical and virtual

Store fields can allow physical entries, virtual ones, or both. A physical entry is a real file on disk or in object storage; a virtual one is a reference to something held elsewhere.

That distinction is what lets a store present files from more than one source as one structure.

Permissions are per store, per group

Each grant names a security group and what it may do. So one store can be readable by everybody and writable by a few, and another visible only to a single team.

Grant stores, not folders

Permissions attach to the store. If two sets of people need genuinely different access, that is usually two stores rather than one store with an arrangement of folders nobody can enforce.

Designing the store boundaries around who may see what is the decision that makes the permissions simple.

Design the tree before loading anything

A store that grows organically becomes a place people cannot find things in, and reorganising it breaks every reference to a file inside it.

A shallow, obvious structure — by year, by customer, by type — beats a deep one that reflects an organisational chart that will change.

Versioning is per entry

Replacing a file creates a new version rather than overwriting. Worth knowing both because it protects you and because it means a store grows faster than the files people think they have put in it.

Review the grants

File stores accumulate access. Somebody added for a project, a group repurposed, a store created for one team and now used by three. It is a short list per store and worth reading occasionally.

Use "View File Store" from the row

The store’s contents are reached as a row action rather than from a menu. That is easy to miss, and it is where you actually work with the files.

Worked example

An organisation runs three stores — public assets readable by everybody, customer documents restricted to the account team, and HR files restricted to two people. Each has a shallow tree by year. Splitting by audience rather than folder made the permissions a three-line answer.

Recommendations

• Separate stores by audience, not folders within one.
• Design a shallow tree before loading files.
• Remember versioning — stores grow faster than expected.
• Review grants per store periodically.