“Should I have Workspaces & Partitions in my Marketo instance?”, is a pretty common question. And the answer is not obvious as there are advantages and disadvantages you should know. Let’s take a look.
Workspaces
Let’s discuss Workspaces first as they are a pre-requisite to having partitions. Without Workspaces – no Partitions.
Workspaces divide assets (whereas Partitions divide persons). So they are a sorting mechanism like folders. But unlike folders, Workspaces also regulate access to assets on user level. (There is a lot of wailing among Marketo users that you cannot also limit user access on folder level, but so far Adobe didn’t listen). Limiting user access is a very useful feature, if – and only if – you have Marketo teams working on different things. “Different things” can for instance mean regions – so you’d have Workspaces like
- EMEA
- North America
- APAC
and you don’t want users from EMEA interfere with assets that belong to North America.
Or think business lines, as in
- Product A
- Product B
- Product C
At first glance, this makes all the sense in the world, but know that there are some things to consider: Workspaces create meaningful borders in your instance. While it might be useful that user A cannot access stuff in Workspace B, user A can also not reference anything outside of their workspace. While many assets can be shared across workspaces – templates, snippets e.g. – some cannot. Like forms. Or Smart Campaigns. That can be a severe hinderance for your – let’s say: central – operations team to create centralized processes.
You can also not clone programs across Workspaces if you don’t make sure that all dependencies of that program are also present in the target workspace.
I’m not saying that these restrictions can’t be overcome, but they are noteworthy and can even be pretty painful.
Generally speaking: If you don’t have decentralized teams that work their own stuff, don’t have workspaces.
Be also aware that Workspaces only have one level. You either divide your teams by regions or by products.
Partitions
Partitions can only exist with Workspaces and they are associated with Workspaces. Often in a 1-to-1 relationship but also one Workspace can be associated with more than one partition or vice versa. Partitions separate the database, so that by default one person – or let’s say: one email address – can only be in one Partition at the same time. (You can create exceptions from that rule).
So what’s the idea here? If you have a workspace “North America” that only your US team can access, you might also want to have a Partition “North America”, so your US team can only email to persons in that Partition. You cannot send an email from the EMEA Workspace to a person the North American Partition.
Think about the implications. That can be good or bad. If you have one English language email to you want to send to American, British and Australian audiences, you can’t to that. Or let’s assume you separated your Workspace by product lines: You cannot – at least not just like that – send a cross-sell offer for Product A to the audience for Product B.
Or another scenario: You have a form in the German workspace that is associated with the German partition. A person that already exists in your database in the Austrian or Swiss Partition submits that form – your customers don’t care or know that they are partitioned – but they won’t trigger any Smart Campaign that listens to that Form Submit, because the Smart Campaign lives in a Workspace their Partition is not associated with.
So let’s sum this up: If you have that decentralized team that cares for different regions or products and you decided to have Workspaces, and you also don’t expect overlap in people between these regions or products, then think about having Partitions too. If none of these apply, don’t have Partitions.