Dynamics CRM : Difference between Site and Sales Territory - dynamics-crm-2011

I am creating organization architecture in dynamics CRM.
I have one question regarding - Site vs Sales Territory
or BU vs Site
When exactly we should create Site, Sales Territory or BU ?
Or we can say what are the limitations of them ?
I have gone through many forums and websites but not able to find any good document on this.
Any online book which I can read to understand this difference ?
Any help on this will be greatly appreciated.
Thank you,
Mittal.

Those are all quite different things used for different purposes. You may find you will need all three or just a couple depending on what you are trying to do. E.g. If you are not doing any sales you wont need sales territories, if you want to model a security model where only some users can see some data you will want business units.
I would suggest digging into each area in more detail (scheduling, sales, security) as described below to make that decision.
Sites are part of the scheduling engine.
In Microsoft Dynamics CRM 2011, a site entity represents a location or
branch office where an organization does business. Many Microsoft
Dynamics CRM customers have multiple sites. Sites enable resources,
services, and appointments to be defined at a particular location with
an associated time zone. Location, correct selection of resources, and
time zone are important elements in the scheduling of service
appointments when multiple locations of doing business are involved.
You can use sites to limit what resources, such as users and
equipment, can be scheduled for a specific service activity.
When you search for an available service activity resource calendar
time slot, to avoid making an appointment in the wrong location, the
scheduler must be able to select the site or delivery location as a
constraint to the search. For example, a customer may ask for an
appointment at the Seattle office. To support this, there must be a
site named Seattle and there must be required resources assigned to
the service type to be performed. When generating appointment
proposals, Microsoft Dynamics CRM 2011 must be able to avoid proposing
appointments with resources that cannot physically be together to
provide the service. The site entity serves this purpose. Sites
provide for the grouping of resources, such as users and
facility/equipment, services, and appointments, according to a
location with an associated time zone and locale.
Sales Territories are part of the sales process.
Microsoft Dynamics CRM 2011 uses the fiscal calendar entities and the
territory entity to track sales information for a salesperson. A
salesperson is a user in Microsoft Dynamics CRM who has to meet sales
objectives, such as sales quotas. A territory is a geographical area
that is assigned to a salesperson.
Business Units are part of the security model.
An organization in Microsoft Dynamics CRM, such as a holding company
or a corporation, is made up of business units. A business unit is a
unit of the top-level organization. Business units can be parents of
other business units (child business units). The first business unit
created for an organization is called the root business unit.
A business unit can own records as defined in the ownership type in
the metadata definition for an entity.

Related

Change Security Role to Business Unit from only blank and Organisation CRM 2013

In CRM 2013 I would like Business Units to have distinct Products that aren't shared amongst them.
However you can only set Products Security Role as "Organisation" or "None Selected"
How would I be able to specify Business Unit Security settings?
Is it even possible?
Entities, can be owned by Organization, User or a Team. Product Entity is owned by Organization so it can be viewed by whole organization. Organization-owned entities typically contain data involving something that belongs to or that can be viewed by the whole organization. Organization-owned entities cannot be assigned or shared.
Have a look at Entity Ownership and please check this blog for more.

Enhance MS Dynamics CRM role based security model

I need to enhance MS CRM Role based security model with more criteria to filter on. I.e. in addition to Business Unit access level, I need to add location access level, team access level and some other access layers based on custom entities.
I brushed through internet and MS CRM 2011 SDK but haven't found an example, how I can enhance Role based security model. Is it possible?
If it is, can you point me on example how I can achieve this?
In CRM 2011 you have more options in security model:
You have the concept of teams, that can have users from different BUs
You have security-field, to enhance the security for a field
See here resume of all options in CRM 2011. See also this article.
Another option you have is using Javascript to add more criteria:
http://www.powerobjects.com/blog/2011/10/20/how-to-hide-a-button-on-the-ribbon-in-dynamics-crm-2011/
http://blogs.infinite-x.net/2010/11/16/retreiving-user-roles-in-crm-2011/
http://crmdm.blogspot.pt/2011/03/how-to-hide-show-tab-in-crm-2011-using.html
http://crmdm.blogspot.pt/2011/02/how-to-hide-control-in-ms-crm-2011.html

Syncing CRM 2011 and SharePoint Security

I have integrated our SharePoint site and our Dynamics CRM 2011 system so that we can upload documents from CRM. But i had a thought that through security in CRM users can only see records relevant to them, but if they just went to the SharePoint site they'll be able to see documents related to any record even if they couldn't see it in CRM.
So i was wondering if its possible in some way to 'sync' the security from CRM into SharePoint so that users can't see what they're not meant to in either system.
Thanks
It is possible out-of-the-box. There is a commercial CB Replicator solution that solves exactly this problem. It performs complex mapping of CRM security model into SharePoint groups and and folder level permissions.
Shortly described it deploys tiny plugin into CRM that collects all the events that could require change of permissions. There is a standalone service that gets these events and write proper permissions into SharePoint as item level permissions on referenced folders by sharepointdocumentlocation entity.
It support various action in CRM that lead into permissions change, e.g.s security roles, business unit hierarchy, privilege depths, team membership, access team, access team templates, sharing.
Unfortunately this isn't possible out of the box. SharePoint's security model is usually based on AD groups, whilst CRM uses in-app security roles applied per user.
To keep these in sync would require some custom development on the server side, that is if it's possible at all.

Complicate security rules

I have been tasked with something that seems a challenge in the security world. The problem is to build a website that has:
Complex ACLs and view permissions. eg. A customer's transaction history should only be displayed in a portal for the customer support agents.
Multi-branded. eg. If the customer support agent is Microsoft then they should have access only to that subset of users and to have the site look'n'feel match their brand. If the agent is Apple then do likewise with their customers and brand.
Item #1 is standard security. Item #2 (multi-branding) seems to overcomplicate things.
To meet the above requirements it seems that each portal and access request will need to take into account things such as: brand being viewed, user roles, objects and their membership to a given brand.
How do I go about tackling the above? Is there any literature on how to build a secure, multi-branded site?

What are the advantages of MySites in Sharepoint 2007?

I'm attempting to justify this functionality to my boss.
So as the title says, what are the advantages of mySites in SharePoint 2007?
We were exploring the use of MySites as a repository of useful information on the employees. As an example, I could convey my skill set through MySites (i.e. ASP.NET, JavaScript, etc.) and then someone else could do a search for that skill set and be presented with people like myself. You could do the same thing with project experience, etc..
We were also exploring the possibility of importing information from AD and our HR database, associating it with employee profiles in SharePoint, and then making that information accessible through search. You could see the organizational hierarchy, phone numbers, departmental information, etc..
Lastly, individuals can use MySites as a way of sharing information (Word documents, etc.) with other employees. This is an alternative to emailing documents, hosting them on network shares, creating shares on desktops, etc..
Unfortunately we hit a road block (huge changes in the company) that have put this initiative on hold - but we were really excited about doing this and it seemed like a real possibility as we began exploring the functionality in dev.
For me SharePoint 2007 MYSITE is a central location to manage and store users' documents, content, links, and contacts.
SO far I have not explored other possibilities.

Resources