+ All Categories
Home > Documents > Business Units and Security Roles

Business Units and Security Roles

Date post: 09-Feb-2023
Category:
Upload: independent
View: 0 times
Download: 0 times
Share this document with a friend
21
Business Units and Security Roles When a business unit is disabled the users in that business unit cannot access CRM users of a disabled business unit will still consume a CRM Licence child business unit users will also not be able to access CRM the records of a disabled business unit user are not disabled. To delete a business unit you must remove all child business units and any users or teams linked to the business unit To delete a business unit you must disable it first Each business unit has a default team of the same name you cannot add users to a default business unit team you cannot delete a default business unit team Equipment/Facilities and Resource Groups do not need to be removed before you can delete a business unit business units can have separate security roles, even with the same name! Disabling a business unit (and child business units) will mean all the users in that business unit won’t be able to login to CRM. moving business units is done by changing the business units parent The Root business unit is a default business unit which has the same name as the organisation. You cannot delete the Root business unit, you cannot disable it You cannot create a business unit above the Root business unit, e.g. you cannot give it a parent. Business units are used to create a hierarchy and this is in a tree structure. The Root business unit will be at the top. none of the data is affected by disabling business units, its only the users who cannot then log in but it is important to take into account all the child business units will also be disabled. This only applies to inherited roles. Roles that are created in a BU explicitly will move with it The users are not disabled but cannot login into CRM whilst the business unit is disabled. As soon as the business unit is enabled they will be able to log into CRM again. if you want to delete the business unit then you will need to change all the users/teams that are assigned to that business unit. You also need to disable the business unit before you delete it. You cannot delete the default business unit team but it won’t stop you deleting the business unit because this will be deleting automatically when you delete the business unit.
Transcript

Business Units and Security Roles

When a business unit is disabled the users in that business unit cannot accessCRM

users of a disabled business unit will still consume a CRM Licence child business unit users will also not be able to access CRM the records of a disabled business unit user are not disabled. To delete a business unit you must remove all child business units and any

users or teams linked to the business unit To delete a business unit you must disable it first Each business unit has a default team of the same name you cannot add users to a default business unit team you cannot delete a default business unit team Equipment/Facilities and Resource Groups do not need to be removed before you

can delete a business unit business units can have separate security roles, even with the same name! Disabling a business unit (and child business units) will mean all the users

in that business unit won’t be able to login to CRM. moving business units is done by changing the business units parent The Root business unit is a default business unit which has the same name as

the organisation. You cannot delete the Root business unit, you cannot disable it You cannot create a business unit above the Root business unit, e.g. you

cannot give it a parent. Business units are used to create a hierarchy and this is in a tree structure.

The Root business unit will be at the top. none of the data is affected by disabling business units, its only the users

who cannot then log in but it is important to take into account all the child business units will also be disabled.  This only applies to inherited roles. Roles that are created in a BU explicitly will move with it

The users are not disabled but cannot login into CRM whilst the business unit is disabled.  As soon as the business unit is enabled they will be able to loginto CRM again.

if you want to delete the business unit then you will need to change all the users/teams that are assigned to that business unit.  You also need to disablethe business unit before you delete it.

You cannot delete the default business unit team but it won’t stop you deleting the business unit because this will be deleting automatically when you delete the business unit.

When you disable a business unit, it disables all child business unit.  The users in these business units will not be able to login

When you change the parent of a business unit, it removes and rebuilds all thesecurity roles of the inherited security from the parent business unit.  So all the users in the business unit will have no security roles and they will not be able to login

Users can login if they are part of a team which has security roles.  They won’t be able to set any personal options.

You can change the Name of a business unit. You Can change the name of the root business unit.

Security Roles and Teams if a user doesn’t have a security role he cannot access the system, so every

user must have at least one security role. Security roles are linked with the user business unit to calculate what

records the user can access. Users receive their permissions to work on records or use features based on

the combination of Security Roles they are assigned and the Business Units to which the users belong.

Security roles can also be assigned to teams and if the team a user is a member of has higher security privileges then this will override their individual security roles.  The user will also use the highest security levelsit is assigned, whether that’s from a security roles assigned to the team or individual security role

Users can be assigned multiple security roles, this means it’s possible to create security roles just for single purposes.

There are 15 default security roles in CRM  The default security roles are all created in the root business unit. A security role stays in the business unit it is created in and they copy down

to any child business units.  if you create a security role in the root business unit then the security

role will be copied to all the child business units below it. User can be assigned any security role which exist in their business unit. only security roles which exist in the root business unit can be added to a

solution file. it’s quicker to modify existing security roles than create new ones All security roles are the same except the System Administrator role which is

a super role. The System Administrator role automatically has access to all records and

entities, including all custom entities.  It has the default access level of organisation for all privileges.

At least One user must have the System Administrator role, this is by default given to the user who installed CRM

Multiple users can be assigned the System Administrator role and you can remove the role from users but you cannot remove the role if that user is the only user who has the System Administrator role.

The System Administrator role also is given the System Admin field level security role, which as I’m sure you can guess gives them access to all field level security.

It’s possible to copy the System Administrator role and it will create a security role but the security role will not automatically have access to any new custom entities added and it basically won’t have the special powers of the System Administrator role.

Teams have security roles (this can affect which form is used) There are some privileges which do not have organisation levels these are

always show under miscellaneous privileges and these are either true or false.These are things likeGo OfflineExport to ExcelPublish articles 

Manage user access, Teams and sharing

The security authentication in CRM is not really handled inside CRM.  A bit like the way CRM lets outlook/email router do all the emailing, CRM also gets another piece of software to do the authentication of users.

the most common authentication method is active directory You can also used Internet facing deployment (IFD) where the authentication is

either AD FS (active Directory Federation Services) or STS (Secure Token service)

Online security – Microsoft Online Subscription Program (MSOP) A user can have one manager which is a user lookup field on user record

Functionality to manage users and you can find these by going to Settings – Administration

Creating users, teams, Security Roles assign/move users to teams, assign security roles to teams and users Disable business units Delete Security roles, Delete teams Move users between teams Manager

Users You cannot delete users in CRM you can only disable them If you disable a user the user won’t be able to log into CRM a disabled user doesn’t use a CRM license The records assigned to the user are still active.  Best practice is to assign

all the records assigned to the disable user to another enabled user. You need to work out if the user is used in the workings of any workflows,

these will still work but it’s not good practice to assign records etc to an disabled user.

Users must always be assigned to business unit and can only be assigned to onebusiness.

Security roles and teams security roles are additive, so adding a user to a team won’t remove any security privileges to the user

Teams Teams are optional Two types of teams Access teams and owner teams Owner Team can own records Owner Teams can be assigned security roles Access teams cannot own be assigned security roles or own records. An owner team can be converted to an access team An access team cannot be converted to an owner team Each business unit create a default team which you cannot delete and you

cannot add members to Teams can be assigned security roles Team and users can be the owner of records

 

Business units and default owner teams Business units have a team created automatically, the team name will have the

same name as the business unit.  Any members created and assigned to the business unit will automatically be added to the default business unit team.

It’s a dynamic team which CRM keeps up to date. It cannot be edited but you can assign security roles and these security roles

will apply to all members of the business unit. default business unit team cannot be re parented, deleted or renamed and it’s

members cannot be modified.

SHARING

In CRM you can share records between users and teams.  Sharing gives the user being shared to the same privileges to that individual record as the user who is sharing.

Sharing bypasses business unit – access level parts of security because when you share records it basically ignore the level (organisation, business unit, user)

Sharing records to a team is like sharing the record with every member of the team, except in the PrincipalObjectTable this is only one entry

using the business unit default team you can share records to all users in different business units.

You can share more than records, you can also share Charts, Views and Dashboards.

Users can only share their personal views, charts and dashboards. When a user shares the components (charts, views and dashboards) they also

choose what privileges you want the user/team to have with the componentThe privileges you can share areReadWriteDeleteAppendAssignShare 

Re-parenting users/teams  Re-parenting a user/teams business unit has a drastic effect on the security

roles the user or team had, it REMOVES THEM ALL.  So if you ever change a user/teams business unit you will need to assign the

user or team some security roles in the new business unit. This sounds drastic but it actually makes sense if you think about it

logically.  Each business unit has it’s own set of security roles, these are usually copied down from the parent business units.  So when you move businessunit, it removes all the security roles and it can’t automatically add them all back because not all the security roles may exist in the new business unitor the security roles could be vastly different with completely different privileges, so the user must add new security roles.

This is also true if you re-parent a whole business unit because all the userswill have had all their security roles removed.

Remember users without security roles cannot log into CRM. If a user is re-parented they lose their security roles but they won’t be

removed from any teams, this would probably allow them to login to CRM but theuser won’t be able to change any personal settings, or view any components theuser created.

If a team is re-parented then every member of team will lose all their security roles because the team will have had all it’s security roles removed.

An efficiency trick is if you want to remove all the security roles for a useror team is to move business unit 

AUDITING Auditing has three levels – Global, Entity, Field Auditing is enabled in System settings and then for each individual entity Any entity can be audited if auditing is not enabled at organisational level, it doesn’t matter if

auditing is turned on at an entity level, nothing will be audited. audit logs are partitioned every 3 months.  These can be  deleted in the audit

log management screen User has to have the View Audit History privilege when you turn on auditing for an entity, all the available fields are by

default enabled for auditing Audit logs management is done by a system job Some System fields are not applicable for auditing

CreatedOnCreatedByModifiedOnModifiedByOwning Business UnitOwning UserCustomer AddressId 

Access Teams and Access Team Templates

 Access teams are new functionality added in CRM 2013 (so expect some questions)

Access Teams and Access team templates are a method to share permissions and records, which is easier to manage, quicker to add/remove users/teams because Access team templates will applying a standard set of privileges (read, write,delete, append, append to) rather than having to set this up for each individual user/team.

Access Team templates are enabled on an entity basis and you have to enable Access Teams on the entity in the communications and collaboration section

Access teams can be ticked and un ticked on an entity (unlike Queues) You need to customize the form of the entity you want to add the Access Team

Template to and in my case it’s the account form

You need to add a sub grid to the form Records – All TypesEntity – UsersDefault View – Associated Record Team

MembersTeam Template – Hosk Account Access Team – this is the team template I created in the step before, yours is probably called something different.

When you add a user to the user grid it will automatically create an Access Team but the odd things is you can’t view this team in the Teams section in Administration

You can view access teams by using the advanced find, search for Teams and choose of type Access.

You add users to the access team via the sub grid on the record. you can add users directly to the access team. You can more than one Access Team template for each entity The default number of access teams templates for each entity is two The number of access team templates you can have for each entity is controlled

by theMaxAutoCreatedAccessTeamsPerEntity deployment setting. MaxEntitiesEnabledForAutoCreatedAccessTeams deployment setting has a default

value of 5.  This controls the number of entities it’s possible to enable for auto-created access teams.

You can change the MaxEntitiesEnabledForAutoCreatedAccessTeams , MaxAutoCreatedAccessTeamsPerEntity  only on Premise installations and you cannot edit them for Online.

A system generated Access Team isn’t created for each record until you add a user to the sub grid on the entity.

if you delete the team, this is the same removing all the members in the sub grid on the record.

if you change the access rights on Team Template this will only change the access right to new entity records/access teams.  Any records already created will use the previous set of privileges.

Access teams with Share access right ticked will mean any user who is in access team will be able to add (share) others to the access team for that record.

Users cannot grant privileges they do not have.  So a user can only add new members to an access team where the access team template has delete privilege only if that user has the delete privilege for the entity.

Access Teams created automatically by adding users to them are not shown in the system team views

If you want to delete a Access Team Template you will need to remove all the sub grids using that specific Access Team Template before you can delete it. Owner Team

Owner teams in Microsoft Dynamics CRM can have security roles Team can own records

Access Team Access teams cannot be granted security roles Access teams cannot own records Accesses records through sharing Sharing privileges are defined by an access team template but don’t change

dynamically for existing records if the template changes Access teams are not displayed in most system views You can add/remove users directly on the subgrid of the record you want to

share access to. 

Field Level security Enabling or disabling of field level security by setting the IsSecured

attribute cannot be audited. System Admin is has all privileges on all field level security fields, the

user has a System Administrator field security profile where all values are set to yes and will be for any fields checked for field level security.

Every field enabled for field level security is added to all field level security profiles

when you turn on field level security for a field, it will automatically be added to all Field Level security roles with Read, Create and Update all set to No.

New field level security fields can only be seen by users with the System Administrator role, so you have to go and configure the field level security privileges.

Every field level security profile will include all fields with field level security enabled.

Fields that are ticked for field level security will be added to field security profiles but with Read, Update, Create all set to No, so you must go in to configure

users/teams can be added to more than one field level security profile. *** asterisks show if a user does not have read access to a field *** asterisks show even if the field is null/blank You cannot delete the System Administrator field level security profile You can only set field level security on custom fields!

These notes are the to revise the key concepts of solutions for the MB2-703 – Microsoft Dynamics CRM 2013 Customization and Configuration certification

Config – teams, security roles, business units, Entities, views Customization – standard GUI changes, forms, entities, views, GUI workflows,

business rules

Extending CRM – Code changes – javascript, .NET, plugins, custom workflow, console application

Configuration and customization could be used when talking about changing the same components e.g. Entities, Views

Extending = code related changes. Microsoft Dynamics CRM 2013 Software Development Kit is used to create and

deploy plugins, Web Resources and custom workflows. What cannot be added to a solution

Business Units Teams Queues Goals Subjects Product Catalog

The items above must be either created manually or imported.  If you want to create manual data and use the same guids between systems then you will need to export and import the data so you can specify the guids used.What Can be Added to a Solution?The following is a list of solution components that you can view within a solution

1. Application Ribbon2. Article Template3. Business Rule4. Chart5. Connection Role6. Contract Template7. Dashboard8. Email Template9. Entity10. Entity Relationship11. Field12. Field Security Profile13. Form14. Mail Merge Template15. Message16. Option Set17. Plug-in Assembly18. Process19. Report20. Sdk Message Processing Step21. Security Role22. Service Endpoint23. Site Map24. Web Resource

 

Solutions in Microsoft Dynamics CRM is a method to let you group and manage your custom components for a particular set of functionality or release

solutions are optional When an organisation is created a Default Solution is created which contains

all the components You can export the default solution but only as an unmanaged solution Solution best practice is use it to split up business requirements probably

either in Sprints/releases or in business requirements. It’s possible to export the Default Solution and import this solution into

another CRM Instance but you cannot export Default solution from  a CRM On Premise to a CRM On line or vice versa.

There is no limit to the number of solutions you can create Before you can create a solution you must create a publisher, Publisher is a

business required field on solution A publisher has a prefix, The prefix will then be added before the schema name

for the entity or field e.g.o hosk_newFieldo hosk_entityName Managed solutions cannot be exported unManaged solutions can be exported Managed solutions can be deleted, this will delete the solution and all the

entities and data Managed solutions can’t be changed or altered, except by the publisher/owner There are privileges needed to import a solution and publish it. Managed solutions use managed properties Managed solutions automatically publish on import unmanaged solutions have to be published Unmanaged solution components cannot be uninstalled when you delete an unmanaged solution you are only deleted the solution file,

all the changes remain in the default solution Unmanaged solutions can be exported as an unmanaged or managed solution Managed solutions can expose some components to be customized by the end user solutions have built in versioning, if version 1 is imported and then solution

2 is imported, CRM will prompt you to see if you want to overwrite the changesin version 1.

Solution version is major.minor.build.revision Custom solutions developed using Microsoft Dynamics CRM 2011 can be imported

into Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online organizations.

Custom solutions developed using future versions of Microsoft Dynamics CRM cannot be installed into earlier versions without first being ‘down-leveled’ to match the earlier version.

When you export a managed solution, you can’t import it back into the organization it was imported from.

be careful when importing an unmanaged solution because those changes cannot be removed and they will overwrite any current changes

Solutions are additive, you cannot delete any components by importing a solution

You need the System Administrator role to import solutions You cannot import entities or fields with the same schema name to components

that exist in the CRM database. All imported security roles are created in the root business unit managed properties are fully customizable by default. Solutions created in Microsoft Dynamics CRM 2013 cannot be imported into a

Microsoft Dynamics CRM 2011 database. The maximum size for a solution file for Microsoft Dynamics CRM online is

29.296 MB For On-premise CRM 2013, the default maximum size for a solution is 6 MB but

this can be increased. You must have the System Administrator security role to import , organization

settings,  security roles, plug-in assemblies, sdk message processing steps.

Hosk CRM 2011 – Exam Cram NotesFinally I have some study notes I made for the CRM 2011 Configuration and Customization exam, these notes are not detailed but for the final revision stage of the exam, they are basically exam cram notesMy exam notes will show you the detailed knowledge you will need for the exam because any of the information below could appear in the exam.

         a maximum of 2 columns can be used to sort a view          The CRM Administrator can see everything          Audit logs management is done by a system job          decimal precision is set on each currency attribute AND in system

settings          Connection roles, security roles, optionsets, Web Resources,

templates, field security profiles are all included in Solutions          editing CRM website files is unsupported          Auditing is enabled in System settings and then for each individual

entity          business units can have separate security roles, even with the same

name!          When assigned a security role to a user, the choice is filtered by

business unit and the security roles in that business unit          Disabling a business unit (and child business units) will mean all

the users in that business unit won’t be able to login to CRM.          Teams have security roles (this can affect which form is used)          moving business units is done by changing the business units parent          Managed solutions cannot be exported          unManaged solutions can be exported

         Managed solutions can be deleted, this will delete the solution and all the entities and data

         Managed solutions can’t be changed or altered, except by the publisher/owner

         There are privileges needed to import a solution and publish it.          Managed solutions use managed properties          Managed solutions automatically publish on import, unmanaged

solutions have to be published          when you delete a managed solution you are only deleted the solution

file, all the changes stay.          To add 3d effects or modify charts you need to export the chart,

change the XML and then import it.          Optionsets can be used by many entities          Many to Many relationships can be either Manual or Native          Native many to many (N:N)  is done automatically by CRM (it creates

the intersect entity but hides it)          Manual Many to Many relationships are done manually an entity to sit

between the two entities and have a 1 to many relationship with them both.          Custom fields can be used for field level security          built in fields cannot be used for field level security          Each form has a fallback form          A Teams  security role can influence what form is used          Queue functionality cannot be unticked once it has been ticked          Relationships – Cascade active – assigns active entities          Relationships – Cascade all – assigns all entities          Primary keys, created by, creation on, modified on cannot be audited          Find columns are set in the Quick Find view for entities          Business required fields don’t have to have a value if they are not

included on a form          importing data does not go through the same validation (e.g. business

required) because validation is done only on the forms.          an entity can only have one 1:M (one to many) parental relationship          Display option must be filled in for Many to Many relationships          WEB RESOURCE – Silverlight  XAP          WEB RESOURCE – Web page HTML          WEB RESOURCE – Script (JSCRIPT)          WEB RESOURCE – Data (XML)          WEB RESOURCE – Style Sheet (XSL)          WEB RESOURCE – graphics – JPG, PNG, GIF

         Mapping fields must be the same type          mapping optionset values must be the same          APPEND – the entity you want to append          APPEND TO –  The entity have things appended to it          fields used in reports do not create a dependency and can be deleted

Facts and stats about Access Teams, the bits below are useful for those study MB2-703

You can more than one Access Team template for each entity The default number of access teams templates for each entity is two The number of access team templates you can have for each entity is controlled

by theMaxAutoCreatedAccessTeamsPerEntity deployment setting. MaxEntitiesEnabledForAutoCreatedAccessTeams deployment setting has a default

value of 5.  This controls the number of entities it’s possible to enable for auto-created access teams.

You can change the MaxEntitiesEnabledForAutoCreatedAccessTeams , MaxAutoCreatedAccessTeamsPerEntity  only on Premise installations and you cannot edit them for Online.

A system generated Access Team isn’t created for each record until you add a user to the sub grid on the entity.

if you delete the team, this is the same removing all the members in the sub grid on the record.

if you change the access rights on Team Template this will only change the access right to new entity records/access teams.  Any records already created will use the previous set of privileges.

Access teams with Share access right ticked will mean any user who is in access team will be able to add (share) others to the access team for that record.

Users cannot grant privileges they do not have.  So a user can only add new members to an access team where the access team template has create privilege only if that user has the create privilege for the entity.

Access Teams created automatically by adding users to them are not shown in the system team views

Access Teams created automatically can be seen by doing an advanced find and select Team Type = access

Access Team created automatically have the is system managed field set to true Access Teams can be un ticked on an entity (unlike Queues) If you want to delete a Access Team Template you will need to remove all the

sub grids using that specific Access Team Template before you can delete it.

Access teams don’t user the POA tableThe final import thing about access team is they do not write to the POA (Principal Object Access table).  This table holds all the rules about sharingfor users/teams for each entity.  The POV table holds information about sharing and security/access and is read every time a user accesses a record tomake sure they have privileges to view and then update/delete it.   A big POA table with lots of sharing of records can in some cases slow down the system.After reading CRM MVP Adam Vero’s comments it seems access teams do write to the POA table so this isn’t where the advantage of Access teams comes from.On the efficiency side Teams do write fewer records to the POA table than sharing to individual users.Owner teams are good when you want to share records to teams and those teams should have their privileges set by security roles.access teams are good for quick ad hoc sharing of records where the users who will need to use a record may change often.  Access teams allow you to quicklyadd and remove users. Reading the White paper it has a good summary of the key features Owner Team

As teams in Microsoft Dynamics CRM with security roles Can own records Privileges are granted by security roles and change dynamically as the role

definition changes Needs to be manually or programmatically created and managed Will be cached in CRM Server when a user accesses the application Can act as resource in service scheduling

Access Team Can’t be granted security roles Can’t own records Accesses records through sharing Sharing privileges are defined by an access team template but don’t change

dynamically for existing records if the template changes Won’t be displayed in most team views Can be system managed, directly from the form of the record that it relates to Won’t be cached because it doesn’t derive privilege or ownership checks Can’t be scheduled as a resource in Service Scheduling Not shown in team views as typically used at high volumes

What is a solutionSolutions in Microsoft Dynamics CRM is a method to let you group and manage your custom components for a particular set of functionality or release but

remember solutions are optional, you don’t need to have them and you can if you wish just edit the default solution. Default SolutionYou don’t have to have a solution file you can edit the DEFAULT solution by going toSETTINGS → Customizations → Customize the systemDON’T RECOMMEND THIS1.  You could only export these changes as unmanaged which would overwrite theother systems with no way of removing them2.  It would be hard to tell what changes you had made3.  it would take longer and longer to deploy them, manage and update them.

Solution best practice is use it to split up business requirements probably either in Sprints/releases or in business requirements.When an Organisation is created, by default a solution called Default Solutionwill be created which will include all the components in the system.Customizing the default components without a solution is customizing the default solution.   The default solution will also be customizated if you makechanges in a new solution because all changes will be made to the custom solution (unless you have imported a managed solution)It’s possible to export the Default Solution and import this solution into another CRM Instance but you cannot export Default solution from  a CRM On Premise to a CRM On line or vice versa.Why Use solution, how do people use solutionsA solution is a way to package a group of customization’s.  There is no limit to the number of solutions and you can package them up and deliver a whole setof changes in one solution.Solutions provide ways to organize the deployment and development of customization’s.  You can provide releases or new functionality.How do you group the changes, this is personal preferenceyou can group the changes in terms of functionality e.g. reports, project management solution, easy navigation changesOr you can group the changes in terms of a release or sprintyou can create solutions for different types of changes, e.g. workflows, entities, plugins Publishers and PrefixesBefore you can create a solution you must create a publisher.When you create a certain customizations like entities or fields, CRM will automatically prefix the change with the prefix value held in the publisher specified in your solution.  If you are making the change in the default solution, you will be using the default publisher which has the prefix of newThe prefix will then be added before the schema name for the entity or field e.g.hosk_newFieldhosk_entityName

This means if you have two different customizers changing the system with different publishers then they will create components with different prefixes.If you export your Solution as a Managed Solution, the publisher is especiallyimportant because after the solution is imported in the target system only solutions with the same publisher will be able to update those components.  Soeither you can update the components with the same publisher with an unmanagedsolution or you can delete the solutions.Work with Multiple SolutionsImportant conceptSolutions are containers, on the original (DEV) system they do not stop anyonechanging anythingSolutions are containers to manage and show the changes on on the original system.  What these means is if  you had a solution, and you changed the Account entity in your solution.  These changes would show in the Default solution, your new solution and any other solutions which had the account entity in.MYour new Solution is a container for a set of components that work together toprovide the functionality for which you are asked. To modify the components, you can create new components in your Solution, or add existing components from the system to your Solution.Even when you are working in your own Solution, any components you create or modify are changed in the Default Solution, because your Solution only contains references to these components, not copies of the components. This means that if you delete the Solution that you are customizing this removes the “wrapper” around the components – the components remain in the system.This means two customizers can modify components, these changes will automatically be changed in the default solution.  In programming terms this is because solutions only contain references to the components not copies.   Solutions can be seen as wrappers.IF YOU DELETE AN UNMANAGED SOLUTION THE CHANGES WILL STILL BE THERE.  To remove those changes you have to edit those componentsManaged and unmanaged solutionsWhen you export a solution, you can choose to export the solution as a managedor unmanaged type.  I usually remember this by the fact managed solutions are read only when imported into the target system.  What I mean by this is you cannot edit or change any of components.When you import a unmanaged solution all the changes are really changing the default solution, all your changes are copied to the default solution.  Then if you delete the unmanaged solution later the changes will remain.Importing unmanaged solutions will overwrite any changes you had previously made and this cannot be undone and I wouldn’t recommend import unmanaged solutions unless it is from an unmanaged solution from people you work with (and even then think twice) Managed solutionsManaged solutions on the other hand can be edited and only removed by uninstalling/removing the solution, all the components and all the data.  It’s

all gone permanently, even if you then remimported the managed solution all the data would be gone Solution versions – Minor changesone of those questions which once again personal opinionsmall changes to a current set of functionality or solution then you can modify the solution and increment the version number.if it is new functionality then you have to decide whether to add it into an existing solution with version number increment or create a new solution Removing Components from your SolutionRemoving a component from a solution will remove it from your solution but it is not deleted and will still exist in the Default Solution.  You remove a component, you select the component whilst inside your solution and then pressthe Remove button.  This will remove the component reference from your solution but not delete/remove it from the default solution.Don’t get Remove mixed up with Delete.  Pressing the Delete button will deletethe component.  Important System entities cannot be deleted from the system (Case, Account etc), custom components can be deleted.Dependent ComponentsWhen you try and delete a component that has a dependency, it will pop up a dependent component dialog that informs you there is a dependency and stops you deleting the componentif you try to delete a component which has dependencies then you will need to delete the components which depend on the component you are trying to delete.You may have to remove multiple dependencies.Required ComponentsYou can see the required components for a component by selecting the componentand clicking show dependencies.   This will show dependent components and required components.Required components will not prevent you deleting the component.  They are often things like Webresources with JavaScript, plugin, a view.  You don’t need these things in your solutions every time but you will need these components to have been imported into the target system at some point.If you are missing a required component you will get the Missing Required Components Dialog When Adding Components to a Solution.  This won’t stop you exporting the solution.What Can be Added to a Solution?The following is a list of solution components that you can view within a solution: taken from this blog

1. Application Ribbon2. Article Template3. Business Rule4. Chart5. Connection Role6. Contract Template

7. Dashboard8. Email Template9. Entity10. Entity Relationship11. Field12. Field Security Profile13. Form14. Mail Merge Template15. Message16. Option Set17. Plug-in Assembly18. Process19. Report20. Sdk Message Processing Step21. Security Role22. Service Endpoint23. Site Map24. Web Resource

 What cannot be added

Business Units Teams Queues Goals Subjects Product Catalog

The items above must be either created manually or imported.  If you want to create manual data and use the same guids between systems then you will need to export and import the data so you can specify the guids used. How solutions are applied: taken from this great blog post, although I think Ihave seen the picture on the CRM SDK somehwere but I can’t remember whereAll solutions are evaluated as layers to determine what your CRM application will actually do. The following diagram shows how managed and unmanaged solutions are evaluated and how changes in them will appear in your organization.

 PublishingThe majority of components work in the usual way

You make the change (the change is not visible or saved, so if you closed the browser the change is lost)You save the change (not visible to the users yet)you then publish the change to make it visible to all user When you import a managed solution it will publish the changes automatically but if you import an unmanaged solution then you will need to publish those changes.Some components do not need publishing and some doThese components need publishing

Application Ribbon Entity Entity Relationship Field Form Message Option Set Site Map Web Resource

One final point regarding the publishing customizations, users may experience some problems, slowdown so it’s best practise not to publish customizations during working hours and to publish the customizations at time when the systemis not busyExport and Import SolutionsTo move the customizations between systems you can export your solution from one CRM instance and import it into another CRM system.  The solution is exported as a zip file.Inside the zip file there will be a few XML filessolution[Content_Types]customizationsdepending on what customizations you have in your solution there could also bejavascript js files and plugin dll’s, image files etc.It’s good policy to keep backups of your exported customizations in case you need to roll back your customizations.

Entities that can use business process flowsOnly entities that use the updated forms can use business process flows. This includes custom entities and the following system entities: 

Account Appointment Campaign Campaign Activity

Competitor Contact Email Fax

Invoice Lead Letter Marketing List

Phone Call Product Price List Item

Quote

Sales Literature

Order User Task

To enable a custom entity for business process flows, select the Business process flows (fields will be created) check box in the Entity definition.

Note

You cannot undo this action.

Maximum number of processes, stages, and stepsTo ensure acceptable performance and the usability of the user interface, there are some limitations you need to be aware of when you plan to use business process flows:

There can be no more than 10 activated business process flow processes per entity.

Each process can contain no more than 30 stages.

Multi-entity processes can contain no more than five entities.

Advanced FindAdvanced find allows users to create ad hoc queries and save, export and share the results. They are also known as Views. Can be used to search any record type (entity)

Users can create complex filters and queries based on any fields within or related to the record being searched

Can be saved and turned into personal views

Results can be exported to Excel

Advanced Finds can feed charts

Bulk operations can be carried out on Advanced Find results

Actions you can perform on Advanced Find results

o Quick Campaigno Mass Operations: Edits, Share, Activate/Deactivate recordso Add to Marketing List or create a dynamic marketing listo Apply Rule / workflowo Add Relationship (One Record at a time)


Recommended