There is Always a User

Recently I posted about approving SDL Tridion community winners. One of the points that came up was what counts as Tridion today?

Rise of the Connectors

SDL Tridion works with any system that has an API or at least an identifier for its items. A basic approach when integrating Tridion with "external" software is to store such identifiers in a Tridion field and add or "template" the surrounding markup or Web application tag or control to the rendered presentation.

<namespace:tagname id="identifier" /> or

<namespace:controlname id="identifier"

runat="server" />

This works for Analytics, references to external videos (YouTube, Vimeo, etc.), job postings, Linked-In profiles, and more. 

But when the quantity of external items makes this approach tedious and/or when there's software better-suited for certain tasks, it helps to have a more formal (seamless, automated, and preferably with an API) approach.

This is where SDL Tridion leverages its own framework and APIs to connect with systems such as targeting, managed translation, and media management. If familiar with SDL software, you might recognize specific products such as SDL Fredhopper, TMS, WorldServer, SDL Language Cloud, SDL Media Manager, and Campaigns. I've joked that if Publishing was built today, SDL might call it Distribution Manager.

The biggest catches for any such integration include:

• Resolving
• Authorization
• DTAP (I won't write about it here, but keep in mind any integration should confirm its assumptions across CMS, not just delivery, environements)

SDL Tridion now ships with many of these (potential) features out of the box in the form of modules such as (Tridion) Outbound Email, Translation Manager, User Generated Content, and External Content Libraries. To be clear, these connectors are part of Tridion but may come with their own databases, APIs, and user or system accounts. You still need to configure and implement these to meet your project's needs.

SmartTarget is not Fredhopper, but rather the GUI elements, delployer features, and delivery-side code to make Fredhopper work with Content Manager Explorer and Content Delivery.

Translation Manager is not TMS, WorldServer, or Language Cloud. It's the piece that stores, displays, and moves translation jobs between the Content Manager and the translation system. It's managed translation because it tracks the progress of the jobs, automates the process back-and-forth, and lets users search and pick items for translation.

ECL or even the Media Manager Connector is not Media Manager, per se, but the integration between Tridion and Media Manager.

The term "orchestration" is more than (just) a marketing buzzword. It really does fit how SDL Tridion tries to plays nice and coordinate with different users and different systems in one interface (at least until there's a new term).

Even publishing is separate from CM or CD. The Content Manager Explorer interface uses the Core Service except item publish status, which is updated by the publisher.

Connectors Have Users

When I first read the Tridion documentation (back when it was PDF'd and in folders by phases) I didn't understand all the need for user accounts for various services.

The server-side user accounts included tcmsystem, tcmworkflow, tcmsearch, and more. I have since realized that the granularity is important to security (or at least those that care about security). For example the user for Content Managent search probably shouldn't do much more than index the search collection and deliver results.

Tridion's authorization model (as complicated as it seems--Dominic Cronin has pointed out it was built the way awhile back to accommodate certain legacy setups) follows some familiar conventions (groups, rights, and permissions), but it doesn't exactly match other systems. When connecting with Media Manager, Fredhopper, managed translation (TMS, WorldServer, or Language Cloud), or even when publishing or doing workflow, Tridion uses a particular user.

Though you might want finer control, I've seen a few things:

• In many implementations I've seen, the customer will ask to elevate access to make a user be able to do things he or she normally can't. They want more access and an easier integration, rather than more authorization settings.
• The roles allowed to "do" publishing, send translations, pick media, or configure targeting typically own or are trusted with the other system. These tend to be the web publisher, language expert, media owner, or marketer (or marketing SME) that pretty much have full access to the other system.
• If most of my projects have authorization as one of the last things on the list (with good reason, it's hard to know what people will break or get stuck on without using it, also you need to set up sites before restricting what users can access), then finer-grained permissions for these connectors would be "phase 3" projects

The wife, a proposal writer familiar with sales and marketing software, even confirmed with, "Who cares about the types of permission being granted if the main part of the build isn't done?"

Thinking in terms of users explains other scenarios such as:

• In terms of authorization this means users that can see the external items can typically use them, publish them, or send them for translation.
• Rollback acts as the user and requires delete permissions, because a rollback could delete versions of items. The user matters.
• Translation just needs scope on the targets, not sources. You can create a job for any items you can see and you can send a job with items you may not have access to.

Resolutions

Resolving is probably the hardest Tridion functional topic. Add it to your New Year resolutions if you haven't already. Each setup might have a different preference, but Tridion's resolving rules are designed to "make it work." Once you have such a default, you get disagreements with the assumptions. Though I don't always see people wonder why those defaults are there in the first place.

In publishing the basic idea is items that use!your item are republished.

• Why? Because those other items might render your item.
• Why not? A more static content model that explicitly places content on lots of pages means a single item queues lots of other items.

In linking the basic idea is that the link resolves to the closest component presentation.

• Why? Content and pages can be separated and links will just work regardless of where content lives.
• Why not? When content = pages = URLs, which is less of a reality today.

With translation, the owning item (nearest local or localized parent) is resolved except for items not-yet-translated. Duplicates are also removed so the translation job just includes the source items it needs for translators. Not yet translated means items under version 2.0.

• Why? Reduce duplicate translations and avoid translating items not yet translated.
• Why not? See below, but sometimes it's tempting to shortcut a BluePrint design and skip translation Publications. It's also hard to realize there's a difference for a given setup.

The (Can Only Translate) Version 2.0 Myth

I admit that I missed some of these resolving rules. I thought "link propagation" worked the other way around (it doesn't, that's because of our templates might publish linked items). Some might miss the proximity rules in dynamic linking. And for awhile there seemed to be a myth that you can only translate version 2.0 items or that workflow can't send minor versions.

The 2.0 only applies for localized items. Managed translation should have a BluePrint of source and target publications where managed translation "owns" (manages) the translations between sources on targets, which is the typical setup. 

So if you want multiple source publications, then you need matching target publication sets (times the number of languages), otherwise the "Version 2.0 myth" applies. Either way, make this easier by limiting sources, hiding Publications, or using the Publication filters.

Two Users

Users in Tridion that own a minor (temporary) change are the only ones that can see those changes or publish them. To get minor versions to translation in workflow, the translation and workflow users must match. My colleague Eric Huiza pointed this out to me, which helped inspire this post (thank the Huizard).

Update and implementation warning (March 4, 2015): matching identities will let you send translation, but be careful with new items, especially in a reserved state (which are forced to wait for Bundle workflow) since their child items cannot accept the translations until they are unlocked. One approach to avoid dealing with issues with receiving such translations is to automatically increment to a major version for new items.

Which brings us back to the point of this post--there is always a user. If you understand how users are related to authorization, versions, workflow, publishing, and any "new" Tridion connectors, then you've solved the second-most-important question: who.

The first important question is why, but as I've noted, we may not always agree or even consider with the why.

For more technical details on the user and system accounts for the modules and extensions mentioned, see this Tridion Stack Exchange Q&A on user accounts. I'd also love to hear your favorite (or worse) "gotchas" when it comes to authorization, users/user accounts, or extensions/connectors.