Interwoven Teamsite Branches

Interwoven Teamsite had an extremely complex method of managing content publication hierarchy. The content repository could be segmented into branches and sub-branches. A branch would have one Staging area, one or more Editions and one or more Workareas.

An Edition was a snapshot of the entire branch at a certain point. Workareas were areas where users or groups could work on in-progress content. You could control item locking (via check-in, check-out) or resolve workarea differences in Staging.

The overall model was extremely complex, and one of the potential reasons why Teamsite fell out of favor (the other being the decoupled nature of Teamsite as dynamic systems such as Drupal, Ektron, Episerver, Sitecore, and Day CQ became more popular). Most of those systems reduced the complexity to a simple two-stage (editing/draft and published/live) process. Marketers tended to prefer the agility of those systems over the complex governance that Teamsite provided. Additionally, an administrator would need to map these complex branch relationships into a URL directory structure on the rendered site.

That said, with the rise of omni-channel use cases such as kiosk and mobile applications, many headless systems now support functions similar to editions, where an entire set of content may be associated with an external product/application version - so many of these concepts are being revisited to suit product-oriented tasks, rather than web pages. Ironically, the pattern of Teamsite having a form-based content repository, coupled with static site generation and content deployment (via OpenDeploy) is now a very common approach with headless CMS systems. The difference being today the tools today are far cheaper and far more mature (easy content modeling, better APIs, SaaS delivery, extensive APIs and webhooks, easy interface customization, etc.)