Skip to main content

Define your repository folder structure

How should you organize your folders so everyone finds their contracts and only sees what they should?

The repository stores your contracts in folders and subfolders. This structure serves two purposes: finding a contract quickly, and deciding who can see it, since sharing a folder gives access to the contracts it contains.

Take the time to define your folder structure before creating your folders and importing your contracts. A structure planned from the start saves you from moving folders and reviewing access once the contracts are stored.


4 ways to organize your folders

There is no single model. Choose the first level of your folders based on how your teams work and look for their contracts.

By contract type

Example: Customers, Suppliers, HR, Partnerships.

Suited if a single team handles most contracts and looks for them by nature first.

By entity or subsidiary

Example: France, Germany, Spain, then one subfolder per contract type in each entity.

Suited if your group has several companies and each one must only see its own contracts.

By project

Example: one folder per site, program or tender.

Suited if your contracts live and close with a project.

By business team

Example: Sales, Procurement, Legal, Finance.

Suited if each team is responsible for its own contracts and must not see the others'.


Choose your structure in 3 questions

  1. Who needs to see what? If some teams or entities must not see each other's contracts, make this criterion your first folder level: this is the level where you will share access.

  2. How many entities do you manage? Beyond one company, a structure by entity remains the clearest.

  3. How do your teams look for a contract? Start from the most common reflex ("the contract with this customer", "the contracts for this project") to name your folders.


Best practices

✅ Best practices

  • Limit the depth: three folder levels are enough in most cases, beyond that contracts become hard to find.

  • Choose explicit names that all teams understand, and a common language if you work with subsidiaries abroad.

  • Share folders with groups rather than individuals: when someone joins or changes teams, you just add them to the group or remove them from it.

  • Isolate confidential contracts in a dedicated folder, shared with a restricted group.

  • Plan for growth: leave room for a new entity or a new team without reorganizing everything.

  • Validate the structure with business teams before creating it.


What to know before you start

  • Creating, renaming, moving or deleting a folder is reserved for administrators.

  • A folder can be shared in two ways: Share with everyone (the folder is visible to all members) or Share with specific members or groups.

  • A share also applies to subfolders, including those created later. So define the access of your first level before building the next levels.

  • Signed contracts can be stored automatically: in each contract type, the storage step defines a Dynamic folder and, if needed, subfolders created from the contract data.


Next steps

📌 To create your folders and manage their access, see Manage folders and access in the repository.

📌 To store your signed contracts automatically, see Configure contract storage.

📌 To create your groups, see Manage user groups.

Did this answer your question?