SOLVED

Re: Implementing Partitions and Workspaces - Functionality Help

Go to solution
Anonymous
Not applicable

Implementing Partitions and Workspaces - Functionality Help

Hello,

I'm in the process of setting up Workspaces and Partitions for our instance and I have some questions that I can't seem to find any documentation on. We have two brands (so I'm setting up two partitions and/or two workspaces) that don't share leads, so we can have duplicate leads across brands, however, we will not be duplicating contacts or accounts - which I understand will lead to difficulties, but short of revamping the SFDC setup, I imagine I'll have to solve for this on my end.

  1. If a person that exists as a Contact in one partition fills out a form that's associated with the other partition, as I understand it, nothing will happen. How would I make sure a new lead is created? Or potentially better yet (though more unlikely) associate with the existing Contact in the other partition. Is there a way to make the forms global across both Partitions? Based on what I could find it seemed like the answer was no.
  2. If instead of using multiple Partitions I use one main Partition with two Workspaces, is the above problem more solvable? It seems like I should be able to solve for the Contact that fills out a form (since all forms would be shared by the same Partition) but would I be able to duplicate Leads depending on the form they fill out? Meaning, if a person fills out a form for Brand A I want that person to exist, wholly separate from the lead that filled out a form for Brand B (I'd also like two separate Munchkin cookies associated with the two domains).
  3. From what I've read, it seems like I shouldn't use the Assignment rules (assuming I go with two Partitions)  and should instead use workflows in a default partition to move people to one or the other. How would this work with my described setup where I want duplicate Leads but not Contacts? I could filter off of the SFDC Type field to see if it's a lead or contact before pushing to another partition, but unclear how it would actually flow and if I could use multiple munchkin tracking codes for each domain.

Maybe those questions aren't even the right ones, but any help in guiding me during this setup would be greatly appreciated!

Thanks

1 ACCEPTED SOLUTION

Accepted Solutions
Grégoire_Miche2
Level 10

Re: Implementing Partitions and Workspaces - Functionality Help

Hi Steven,

You do not necessarily have to set a 1 to 1 relationship between partitions and workspaces. Assets (smart campaigns especially) are controlled by workspaces and will operate on any person they can access from the workspace they belong to. A partition can be accessed from multiple workspaces.

You should create a few additional workspaces in addition to (and not in lieu of) the 2 workspaces you are planning:

  1. One Master workspace that can access your 2 partitions. In this workspace, you will be able to build forms and workflows that can access all the data. Your Partitions Assignment smart campaigns (better than the rules that are too limited) should also be located in this workspace and will be using any information (including information that can change over time) to assign an reassign records to the proper partition. Only admins / Expert users will have the right to create programs, assets and smart campaigns in this workspace
  2. One training and test Workspace and Partition. These will make an isolated space in which your user can train and test
  3. One best practice WS, with it's own partition too. In this one, you will be able to create sharable elements such as program templates that users will be able to replicate in the BU workspaces

With this structure, you will have more possibilities to implement what you need.

-Greg

View solution in original post

5 REPLIES 5
Grégoire_Miche2
Level 10

Re: Implementing Partitions and Workspaces - Functionality Help

Hi Steven,

You do not necessarily have to set a 1 to 1 relationship between partitions and workspaces. Assets (smart campaigns especially) are controlled by workspaces and will operate on any person they can access from the workspace they belong to. A partition can be accessed from multiple workspaces.

You should create a few additional workspaces in addition to (and not in lieu of) the 2 workspaces you are planning:

  1. One Master workspace that can access your 2 partitions. In this workspace, you will be able to build forms and workflows that can access all the data. Your Partitions Assignment smart campaigns (better than the rules that are too limited) should also be located in this workspace and will be using any information (including information that can change over time) to assign an reassign records to the proper partition. Only admins / Expert users will have the right to create programs, assets and smart campaigns in this workspace
  2. One training and test Workspace and Partition. These will make an isolated space in which your user can train and test
  3. One best practice WS, with it's own partition too. In this one, you will be able to create sharable elements such as program templates that users will be able to replicate in the BU workspaces

With this structure, you will have more possibilities to implement what you need.

-Greg

Anonymous
Not applicable

Re: Implementing Partitions and Workspaces - Functionality Help

Thanks, Grégoire Michel!

A couple quick follow up questions:

  1. One training and test Workspace and Partition. These will make an isolated space in which your user can train and test
    • I have a master Sandbox account where I'm building all of this out first. My plan was to provide access to users so they could test stuff here. Besides the overhead of maintaining the sandbox, do you foresee any shortcomings with this approach?
  2. One best practice WS, with it's own partition too. In this one, you will be able to create sharable elements such as program templates that users will be able to replicate in the BU workspaces
    • Is the intention of this WS to be the holder for all templates? I guess I'm a little confused as to why we would want to create another Partition for this if it's just for the templates. Would you kindly expand on this one a bit?

Thanks again

Grégoire_Miche2
Level 10

Re: Implementing Partitions and Workspaces - Functionality Help

Hi Steven,

I have a master Sandbox account where I'm building all of this out first. My plan was to provide access to users so they could test stuff here. Besides the overhead of maintaining the sandbox, do you foresee any shortcomings with this approach?

No, that's perfect, I recommend that you ask support to enable UID on both your instances, so that users can switch from one to the other without having to disconnect/reconnect. I find that paying for a sandbox just for this is not necessary, as a separate WS does the job. Also, it's much easier to share elements (e.g. templates) with a WS than between 2 instances.

Is the intention of this WS to be the holder for all templates?

LP templates, email templates and also program templates, yes.

The interest is that you can control who can access this WS and it has no data in it, which makes template testing safer.

-Greg

Karen_Black
Level 5

Re: Implementing Partitions and Workspaces - Functionality Help

Question for you since you are an Expert in this area .

Do you see any negatives to making workspaces based on technologies?  When we first set up our instance, we did partitions and workspaces by geography.  We want to keep partitions as-is, but we are seeing a need to change our workspaces around a bit so that certain technology groups only have access to their workspace.  Let me know your thoughts.

Alex_Coussy
Level 1

Re: Implementing Partitions and Workspaces - Functionality Help

Hello Steven Musche , I am just curious if you got your situation solved? I am asking because I am in the middle of a marketo implementation and we also have two brands in two separate markets, so this is very relevant!

Also did you use the help of a marketo consultant or you built it all yourself? So I know what's the cost involved with partion/workspace.