3 Replies Latest reply on Jun 6, 2018 11:58 AM by Grégoire Michel

    Implementing Partitions and Workspaces - Functionality Help

    Steven Musche

      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

        • Re: Implementing Partitions and Workspaces - Functionality Help
          Grégoire Michel

          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

          1 of 1 people found this helpful
            • Re: Implementing Partitions and Workspaces - Functionality Help
              Steven Musche

              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

                • Re: Implementing Partitions and Workspaces - Functionality Help
                  Grégoire Michel

                  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