One of my challenges with the current project I'm working on is to make our solution behave for each franchise owner as if they are in a system of their own, completely separate from each other. Yet, allow the home office to easily roll-up data from each franchise, push leads and other commonly shared data to each franchise, and run scheduled and manually initiated workflows for every franchise.
By far the easiest and most effective way to keep franchise owners separate is to use a multi-tenant solution. If each franchise were in their own CRM Organization, they cannot see the other franchise data. This also lends itself to developing a common core solution, applied to all organizations, yet allow each franchise to make modifications above and beyond the core solution.
However, a multi-tenant solution complicates the home office solution. You can easily end up with disparate and incompatible solutions that are impossible to merge or roll-up.
We've decided to use the built in business unit structure in Microsoft Dynamics CRM 2011 to keep each franchise separate. Each user role has been duplicated to give the franchisees roles that limit their data access to their respective business unit. For the most part this appears to solve our problem. We can easily roll-up data to the home office root business unit level and enforce a common core solution for each franchise. Business rules can be easily deployed and enforced across the network. The rate situation where a franchisee needs to create additional entities, forms, and workflows can be handled and controlled with business unit specific modifications.
Um, now what?
We ran into a situation that, at first, looked like we weren't going to get around. In a multi-tenant environment, this would have been somewhat simpler to implement, but would have involved denormalization of the data. We have hierarchical accounts where the topmost account represents a national service provider, an NSP. The home office would like to track the business each franchise conducts with the local NSP accounts. At the same time, each franchise wants easy access to common NSP account information and contacts without maintaining their own version.
Altered Access
This sounded like a pretty simple problem, I just need to create a commonly accessible NSP account at the home office level and allow each franchise business unit read-only access to it. They can pick it as the parent for their local NSP account.
In order for the franchise business units to see the home office NSP account, I altered their security role giving them Organization level "Read" and "Append To" access to the Account entity. This wasn't quite what I wanted. Each franchise business unit now had read-only access to each other's accounts.
Let's Share
After undoing this, I changed the sharing permissions on the home office NSP account, allowing each franchise business unit "Read" and "Append" access to the account. It's not quite as easy to maintain, I'll have to write a workflow activity to automate sharing NSP accounts, but it's not bad.
... but not this much!
At first, this looked like it was going to work. However, once you select the home office NSP account as the parent account, any franchise business unit could read the local NSP account. The read permissions on the home office NSP account were applied to the franchisee's local account. Not what I was expecting at all.
It's all about Relationships
After further digging, I ran across Cascading Team Permissions in Microsoft Dynamics CRM, a blog post by Benjamin Whitestone, a CRM Analyst at Armanino McKenna. In it, he explains how the default Parental Account to Account relationship behavior causes the user rights of the parent record to be applied to the child record. Fortunately, Microsoft allows you to customize this behavior.
Change the Type of Behavior from Parental to Configurable Cascading. Then change Assign and Reparent from Cascade All to Cascade None. This prevents selecting the home office NSP account as parent from cascading the organization level read privileges to the franchisee child account.
Now, when the home office NSP account is selected as the parent of a franchisee's local NSP account, only the home office business unit and the owning franchise business unit can see it. On to the next challenge.
No comments:
Post a Comment