Today I’m going to talk about the greatest translation system the world has ever seen, maybe even better than the moon landing, which I could’ve done better, by the way.  Nobody moons over folders like me, folks – I’m the best at it, believe me.  And no more free rides for those sneaky users… joining the cloud like uninvited guests at a Mar-a-Lago party.  Let’s get inheritance under control – time to unleash the power of TRADERS (Trados Research and Development Efficiency Restructuring Squad) to slap some order on those free loaders, making them work for us, not against us.  Stick with me, and we’ll make folder structure great again!

If you got this far and still don’t know what I’m referring to, I’m talking about the account structure, users, folders, resources and how they work together when you are working with Trados Cloud.  Specifically (at the time of writing) Trados Enterprise/Accelerate/Team.  The Cloud Capabilities of Trados Studio don’t really matter here since everyone is an admin of their own personal cloud and will have no problem being able to work with all the projects and resources they need.

Oh, yes… I forgot to mention… Trados Cloud is essentially what we referred to for years as Language Cloud; and Trados Studio (Freelance and Professional), Trados Team, Trados Accelerate and Trados Enterprise all run on the Trados Cloud Platform.  Trados Studio is of course a desktop product, but it does have cloud capabilities and these are the ones that will (for now anyway) be unaffected by the inheritance tax because as a licensed Trados Studio user you’re the boss and have full control over everything you can access through the cloud capabilities.

Back to the account structure and stuff… you can find all the detail around what I’m about to explain in around 11k words here in the Trados Team help documentation.  For this article, Team/Accelerate and Enterprise are similar, and I was prompted to write about this because I often see posts in the RWS Community forums from users who are unable to access projects or resources they have been tasked to work on, and often think this is a problem of the software.  In fact, it’s more likely to be a problem of not understanding the inheritance tax, which may not be that surprising when it needs 11k words to explain it!  Only kidding 😉

It takes 11k words to provide comprehensive documentation that explains really well how to work with users, groups, roles, folders, projects, translation resources, roles, permissions… and of course inheritance.  But my goal in this article is to try and explain it in far less so at least anyone reading it will understand why this is such a smart and controlled solution, and why they might need to dig into a bit better before launching into creating projects for their customers and making the solutions work for them.  If you want to go straight to the simple… ish version and save the long read click here!

Customers and Locations….

But first… “Customers”:

This image is taken from Trados Team and shows “Customers” selected.  I wanted to start with this because RWS provide Trados Team to their Academic Partners for teaching students about translation management systems, and a very common question is what are customers, and we don’t have customers we just have students working on projects.  A similar question arises sometimes from users of Trados Studio Freelance who have this in their menu.  “Clippy’s” smarter grandson in the cloud (Trados Copilot) defines a customer like this:

I threw that in because not everyone is aware of this very useful way to search the help documentation.  The explanation is pretty good, and the links provided are these:

• Customers
• Adding customers
• Viewing customers and customer users
• The “Show citations” link gets you the texts relevant to the links above that were used to create the explanation using AI (but only based on real documentation provided by the Trados technical publication team)

This is a good starting point, and Trados Copilot (let’s use TC from now on…) introduces the terms “Location” and “Folder” which are terms that are interchangeable, depending on how you use them.  Why do I say that?  Well, when you create a new “Customer” you will be presented with this form:

It refers to specifying the location for this customer.  If you add a new Translation Memory you’ll be asked for the location; if you add a new termbase… the location.  Nowhere in the UI, that I can recall seeing, says “Folder” and yet the help documentation refers to them often and explicitly defines them as interchangeable in several places.  So I think that the term “Location” is the visual structure you see in the interface, while “Folder” emphasises the logical position in the hierarchy where resources are stored.

For example:

There are two ways in which you might decide to use these concepts for “location/folder” where you can start to see how you might use a structure like this, similar to the folder structure in your computer, to save projects, translation memories, termbases, users etc.  But essentially you have the “freedom” to do whatever you like!  I say “freedom” in quotes because you do need to follow the rules to avoid tariffs!

Inheritance Tax…

Does this mean I have to duplicate my resources in all these locations to be able to work with them?  The answer here would be… not necessarily!  If you successfully avoid tariffs the answer would be no, but that all depends on how you have structured your resources by placing them in the right places.  Do it wrong, and you may have to do a little additional work (the tariffs!!) to make things right.

Inheritance and Visibility

The visibility of resources is determined by their position in the folder (location) hierarchy:

• Resources saved in the Root folder are visible across the entire system.
• Resources saved in the Customers folder are accessible to all “customer” folders below it.
• Resources saved in specific “customer” folders are only accessible to that customer and its subfolders.

So, suppose a Translation Memory named General_Academic_TM is stored in the Root folder in the academic structure you see above.  It will be visible to all degrees and years.  Meanwhile, a specialised Translation Memory named BA_Linguistics_TM can be stored in the BA Linguistics folder, ensuring it’s accessible only to students enrolled in that program.

Simple enough right?  Now let’s look at another concept you’ll find in the documentation which is the “Home folder”. The “Home Folder” is the folder in which a resource (e.g., user, project, translation memory etc.) is saved.  In some interfaces, it is also referred to as the “Current Folder”.  The Home Folder impacts several key aspects of resource management, in particular visibility for Users (you and I are “Users” for example… we also have “Service Users” but that’s a topic for another day, or look it up in TC).

Users can see and access resources stored:

• In their Home Folder (the location/folder the user was added to)
• In folders above their Home Folder (parent folders)

Users cannot see or access resources stored in:

• Brother folders (folders at the same hierarchical level)
• Child folders if the parent folder has been set to Private.

Wait a minute… we didn’t speak about Users before, and we need to know a little more here before the next bit.  So, users are tied up with Groups and Roles.

How Users, Groups, and Roles Work

Users are the people using the system, like translators or managers.  Each person gets an account and needs to join at least one group.

Think of groups as teams of people who do similar jobs, like a “Translator Team” or “Manager Team.”  Groups make it easy to give permissions to everyone in the team at once.  Each group lives in a folder which decides what they can see and do.  Large folders (like the main “Root”) give wider access, while smaller folders (like a customer’s folder) limit it.

Roles are like job titles that tell users what they’re allowed to do… view projects, edit files, or manage teams.  Examples could include things like:

• Administrator: The boss with full control everywhere.
• Lead Project Manager: A manager with big powers, but only in their customer’s folder.
• Project Manager: A regular manager, with access depending on their group’s folder.
• Linguist: For translators to work on texts.
• Customer Requester: For clients to see their own stuff

In Trados Cloud solutions you can make up your own roles, or use the preconfigured ones already there, and each role can be given the permissions you want that role to have.  It’s a good idea for you to speak with TC on permissions as that’s a big topic on its own!  Maybe I’ll come back to that in another article if it looks as though I need to… read if I think I need to understand it better!

Back to the topic… how are these all connected… users, groups, and roles?

• Users join groups.
• Groups get roles.
• Roles set the permissions, and the group’s folder sets the boundaries (what folders and stuff they can touch).
• Projects: Users see projects in their group’s folder and below it, not above.
• Resources (like translation memories): Users see these in their group’s folder, plus any folders above it (if public).

Public?  Isn’t everything public?  Nope… it is possible to make a location/folder private and this adds further control if you want users to be able to see “almost” everything within a customer (for example) that they have been given access to.  Another one for you to look up with TC, because I want to look at a simple example without over complicating it!!  We’ll use the Food Company example I used when looking at the structure of locations/folders earlier.

• Sophie is a user, a translator.
• She’s in the French Translators group, and this group lives in the folder /Root/Customers/Food Company/Dairy Department.
• Her group has the Linguist role, so she can edit translations.
• Since her group is in the Dairy Department folder, Sophie only sees:
  • Projects: In Dairy Department (like “Cheese Labels Translation”), not in Bakery Department (a sibling folder) or Food Company (above).
  • Resources: In Dairy Department, plus any from Food Company or Root (like a shared “Food Terms” file), if those folders are public.
• If Sophie’s user is saved in the higher folder /Root/Customers/Food Company instead of Dairy Department, she might see more… like projects in Bakery Department (e.g., “Bread Packaging Translation”).  You’d have to fix it by moving her user to /Root/Customers/Food Company/Dairy Department to match her group’s folder.
  • Note: in practice you’d have to remove Sophie altogether and add her back again in the right location/folder because you cannot change that… a tariff!

This capability of inheritance and visibility is intended to keep everyone focused on their own work, using locations/folders to control who sees what!

Now, I have written nearly 2k words and haven’t explained in as nearly as much detail as the help documentation so I recommend you review that.  But now I want to try and address the overriding idea I wanted to try and get to before it became so obvious that it’s difficult if you have never seen Trados Cloud before!!  There would be simply too many questions.  But now we have a better grasp of the concepts, so here’s what I tried to do from the start!

Roles, Permissions, Projects, and Resources in Trados Team

The Simple… ish Version

Key Concepts

• Users: People in the system, saved in a folder (like /Root/Customers/BA Linguistics/Year 1), which determines their base location.
• Groups: Sets of users assigned to a folder, known as the Home Folder, which controls their default visibility.
• Roles: Grant permissions (e.g., “view users,” “manage projects”) and have a Scope, defining the folder(s) where these permissions apply.

Visibility Rules

• Users: See others in their group only unless their role expands visibility.
• Projects: Visible in their Home Folder and child folders, never above.
• Resources (e.g., translation memories, termbases): Visible in their Home Folder, parent folders, and child folders — unless restricted by a private folder setting.

Key Rule

If a user’s saved location (e.g., /Root/Customers/Pharmaceutical Company) is higher than their group’s Home folder (e.g., /Vaccine Department), they may unintentionally see more. To limit visibility, align their user location with their group’s Home folder.

Glossary of Key Terms

I also thought it might be helpful to share a glossary of terms you might come across… although do remember to refer to TC and the help documentation as this is very helpful, and especially since there are a few terms  below I didn’t cover!!

User Management

• User: An individual account assigned a role, permissions, and a location within the folder structure.
• Group: A collection of users assigned to a specific folder with shared permissions and visibility.
• Home Folder: The folder where a user or group is saved. Defines their default visibility scope.
• User Location: The folder where an individual user’s account is saved. If higher than their group’s Home folder, their visibility expands to all child folders below their location.

Roles and Permissions

• Role: A set of permissions assigned to a user or group, controlling what actions they can perform.
• Scope: Defines the folder (and its child folders) where a role’s permissions apply.
• Permission: A specific right or action that can be granted to a role, such as “view users” or “manage projects.”
• Administrator: A system-wide role with full access to all folders and permissions.
• Lead Project Manager: A powerful role that mirrors an Administrator but is restricted to a designated customer folder and its subfolders.
• Project Manager: A role with permissions to manage projects within the folder(s) defined by its scope.
• Linguist: A role for translators and reviewers, often limited to accessing projects they are assigned to.
• Customer Requester: A role designed for clients, often with limited permissions to view and request projects.
• Private Folder: A folder where visibility is restricted to only users in that folder (no visibility propagation above or below).
• Public Folder: The default status for folders, allowing visibility to users from that folder and its child folders.

Projects and Resources

• Project: A combination of translation files, assigned users, and resources such as translation memories, workflows, and termbases.
• Resource: Any supporting element used within a project, including:
  • Translation Memory (TM): A database of previously translated content that aids future translations.
  • Termbase: A database of approved terminology for consistent translations.
  • Translation Engine: A combination of translation memories, termbases, and machine translation resources.
  • Workflow: A series of steps that defines how translation tasks progress through stages (e.g., translation, review, QA).
  • Custom Field: A user-defined label applied to projects for filtering and tracking purposes.
  • Project Template: A reusable configuration that defines key settings for consistent project creation.

Folder Structure and Inheritance

• Root Folder: The top-level folder in the hierarchy that encompasses all customer folders.
• Customers Folder: A folder dedicated to organizing client-specific subfolders.
• Parent Folder: The folder directly above the current folder in the hierarchy.
• Child Folder: Any folder directly below the current folder in the hierarchy.
• Sibling Folder (Brother Folder): A folder that shares the same parent folder as the current folder.
• Inheritance: The visibility propagation rule that allows users to see resources in their Home folder and parent folders.

Visibility and Access

• Visibility: Determines which users can see specific resources, projects, or users. Controlled by folder structure, roles, and permissions.
• Access: Determines what actions a user can perform, dictated by permissions assigned to their role.
• Inheritance Filtering: A method to limit the resources displayed to those located in the current folder or parent folders only.

Practical Examples of Terms in Action

• User in Multiple Groups: A user in multiple groups may inherit permissions from each group, especially when those groups are saved in different folders.
• Dynamic Permissions: Temporary permissions granted when users become task assignees, owners, or completers.