TMS: Hierarchy and Setup Reuse - How many orgs and why?

SDL TMS is a  powerful Translation Management System - and a lot of its power comes from the hierarchical structure.

 

The ability to have multiple levels (organizations) allows you to decide on:

  • visibility
  • content separation
  • reporting separation

That's great, but what does that mean in terms of setup? Do I need to create all my objects inside all the various organizations?

Not quite.

Of course different people have different ways of working - but my rule of thumb is: create each object at the highest level at which it is both useful, and allowed.

Admittedly, that sentence could sound a bit like it came from a fortune cookie, so let me explain.

First of all, let's look at what your organization structure should look like:

Root Organization: this level comes out of the box and is mandatory. It should be reserved for any Admin level users and any other objects which come out of the box with TMS (like content types).

Professional Services: Insert your company name here! This will be the main node in your setup - the common ground for all the objects which are widely shareable.

Other organizations: This is where you get to build your org structure; in my case, I have two organizations at the same level (siblings) and both with the same parent (Professional Services org). These are also often called sub-orgs to the Professional Services org, in this case.

 

At this point, you might be asking: yeah, that's great, but

  ... how do I decide which organizations I need?

 

Organization will normally be related to departments, or business units, or different teams within your company. They can also in some cases be related to different countries/geographical regions - it all depends on what kind of business, or even content separation makes sense in your particular case.

The Main Reasons for Separate Organizations are:

  • you want to restrict user visibility for certain parts of the business
    • Perhaps you have a group within your business which deals with confidential content, for instance
  • you need invoicing/costing in different currencies
    • each organization can only deal with one currency; if you require more than one, you will need multiple organizations
  • you need separate reporting across different parts of the business
    • perhaps they are different business entities, or respond to different cost centres

You may also decide on having a set of organizations which reflects the structure of the business that TMS instance is associated with - just bear in mind that you will then have separate reporting and separate visibility across those organizations, so always try to find a balance between getting the results you want, and making it realistic to manage.

Remember to always have your corporate node underneath Root - and then work the rest out from there.

On the next post I will cover how to find the best balance between reusing setup and having the right level of visibility.

In the meantime, stay warm!