CRM 2013 – How to set up Field Level Security

I have covered all the other aspects of Security in CRM 2013 and now I am left with Field Level Security, which in some ways is apt because this is probably the most strict.

Field level security was a much requested feature when it was added in CRM 2011, probably up there with auditing.

Here is the video walkthrough

Field level security allows you to add extra security around individual fields.  The three security values are

Read

Create 

Update

 

 

Adding Security to a Field

The first rule is, you cannot set field level security for any of the default fields. If you try to the pesky field level security checkbox is disabled.  I’m not entirely sure the reasons for this, the most likely is if you stop people adding values to the default fields then some of the functionality might stop working or the system as whole might not work probably (that is my interpretation of it)

You can only set field level security on custom fields!

So go to record, either create or find a custom field and then enable Field Security

field level 1

If you now look at your custom field on the form then you will see there is a key on the field

field level 2

Publish the changes to the entity and before we add the field to a Field Level Security profile go and have a look at the form, which in my case is the account form.

If you go to the form with a user who has the System Administrator role then you will be able to see the value in field but if you go to that form as another user then you will see some asterisks ****** (even if the field is blank).  The reason all other users see asterisks is because the field is added to field level security profiles (all of them) with the Create, Update, Read values all set to NO.

This means when you add field level security, no users (except System Administrators) will be able to view or edit the field, so you better quickly set it to a field level security profile and add some users.

below is a screen shot for a user who isn’t a System Administrator

field level 3

 

Create Field Level Security Profile

Now we are ready to create a profile.  The order of these steps can catch people out because if you start with Field Level security you might first create your Field Level Security profile and find them blank and then you will wonder how to get fields in there.

Go to Settings –> Administration –> Field Security Profiles

field level 5

 

This will then take you to a list of all the field level security profiles.

Notice the System Administrator is a default team maintained by CRM, although it is possible to add members to the team.

Now edit or create a new field security profile

field level 6

Opening your new field security profile.

If you go to field permission you will see a list of all fields which have field security enabled.

By default the privileges are set to NO

field level 7

 

if you click on one of the fields you can then edit the security

field level 4

The other important thing you need to do is add users/teams to the field security profile (otherwise only System Administrators can view/edit the fields)

field level 9

 

Key Facts about Field Level security for MB2-703 exam

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!

Advertisements

CRM 2013 – MB2-703 – Quick Overview of Auditing

Auditing was added to CRM in version CRM 2011, it was a good move from Microsoft because this was a much requested feature and in CRM 4 it was mainly done using a auditing plugin.

Auditing is one of the straight forward features in Microsoft which does a good job of just working, doing what you need and rarely going wrong.

Auditing is set at various levels

Global settings – do you want to audit

Entity level – what entities do you want to audit

Field Level – what fields on the enabled entities to Audit

You can also audit users, when they log into CRM, when security roles are assigned to the user.

The auditing functionality can be found by going to

Settings – Auditing

auditing 1

Then you can click Global Audit settings

auditing 2

This allows you to start auditing, notice there is also a section for user auditing.

User auditing can be turned on or off, you can change what is audited.

Enabling auditing in the common areas is a way to turn auditing on for groups of entities and fields.

Once you have turned on auditing you can then choose to audit individual fields

auditing 3

Auditing Table

After you have enabled auditing all the auditing changes will be  held in the audit tale in CRM Database.  It will store the user who triggered the event, what type of event and the date of time.

Auditing Key Features:

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 partioned 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 enabled for auditing

Some System fields are not applicable for auditing

  • CreatedOn
  • CreatedBy
  • ModifiedOn
  • ModifiedBy
  • Owning Business Unit
  • Owning User
  • Customer AddressId

To see a detailed list of is audited go the CRM SDK Auditing Overview

CRM 2013 – MB2-703 – Access Teams and Access Team Templates how to use them and key facts

A new feature in CRM 2013 is Access Teams.  For those people studying for the MB2-703 – CRM 2013 customization and configuration exam, you will need to know the difference between access teams and Owner teams.

I personally have not understood the real benefit of Access teams and access team templates, I understood it was an quick way to share individual records but I wasn’t sure how this was different to the current sharing functionality.

First I will go through the Access Teams functionality and then we will focus on the differences

I will also mention Microsoft have a very good white paper on Access Teams which you can download by going to the link below

http://www.microsoft.com/en-gb/download/details.aspx?id=41190

Before I went through sharing and teams in the previous blog\video which you can see using the links below go through more tradition teams and sharing

Blog – CRM 2013 – MB2 703 – Manage user access, Teams and sharing

video – CRM 2013 – MB2 703 – Manage user access, Teams and sharing 

 

Access Teams And Access Team Template Demo can be seen in the video below

The standard owner team/user functionality allows you to share records and components (views, dashboards) to users or owner teams.

This functionality is very useful but the sharing process is not very visible and can be difficult to manage.  Sharing records is done by an individual user and the only way to see what records are shared and to whom is by going to the record/component and clicking the sharing button

access team1

 

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.

An overhead  of Owner Teams and sharing is they write records to the POA (Principal Object Access)  table and this may eventually can result in performance overhead.  It should be noted that sharing records with teams is a lot more efficient than sharing records with individual users because it only writes less records to the POA table (for the team) rather than each individual user.

 

 Enable the entity

Access Team templates are enabled on an entity basis and you have to enable Access Teams on the entity in the communications and collaboration as you can see below on the screen shot.

access team2

Once you have ticked the access teams check box, save and publish (I don’t think you have to publish but just to make sure).

 

Create your Access Team

Go to SETTINGS –> Administration –> Access Team Templates

Click the New button

You now have to create you team name, specify the entity the Access Team will work on and the access rights

access team3

 

Now the next step is not straight forward, when I say that I don’t mean it’s difficult but I do mean most people would never guess what to do next.

Add the Access Team sub grid to the form

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 Types

Entity – Users

Default View – Associated Record Team Members

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

access team4

save and publish the changes

 

now you can go to account records and there will be a sub grid which will allow you to add users to it. These users

access team5

Odd things happen 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 even if you select All Teams or Access Teams.

The only way to view the teams is to create an advanced find, search for Teams and choose of type Access.

You will then see some odd teams with Guid names

access team6

if  you click on one you can then view the details.  So you will get a new team for each entity and access template type.

To help identify the different teams you can put something in the description

access team7

You can also add and remove members in this screen.  If you remove all members the team will disappear until you add another user to it.

 

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 the MaxAutoCreatedAccessTeamsPerEntity 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 table

The 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 sharing for 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 to make 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 quickly add 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

 

CRM 2013 – MB2 703 – Manage user access, Teams and sharing

In this blog post I will continue looking at the security features in CRM with regards with understanding the information for the MB2-703 – CRM 2013 Customization and configuration exam.

I will be focusing on

  • Manage access.
    • This topic may include: manage users and teams; configure sharing; manage Security Roles for users and teams; create Access Team Templates; add Access Team subgrids to forms

To see the topics in CRM 2013 then watch the video

This involves users/teams and sharing records and components and a little bit about authentication

 

Authentication

 

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.

 

on premise

most commonly user records are linked to active directory

You can also used Internet facing deployment (IFD) where the authentication is either

AD FS (active Directory Federation Services)

STS (Secure Token service)

 

online

Microsoft Online Subscription Program (MSOP)

 

Either type of authentication the security authentication is done and then if successful the user are signed into CRM and then CRM applies the correct security roles, privileges.

Managing Users

There are a number of 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

 

each user can have one manager assigned to them.  The manager look-up can be found on the user record, I  think it’s used in routing.

access

Security roles – Security Privileges

Business management tab has the security privileges

Security role

Team

User

User Settings

Business Unit

Field Level Security

access 2

Miscellaneous Privileges

Enable or Disable user

Re-parent business unit

enable or disable business unit

re-parent team

 

Disable a user

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.

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

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.

default teams can be converted to access teams but you cannot convert access teams to owner teams.

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.

 

Share more than records

 

Not only can you share records but also 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 component

 

Read

Write

Delete

Append

Assign

Share

access 4

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 business unit, 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 unit or 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 reparent a whole business unit because all the users will 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 the user won’t be able to change any personal settings, or view any components the user 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 user or team is to move business unit

 

CRM 2013 – MB2-703 – Business Units and Security Roles Study Information

15 percent of the exam is based around security so you need to know it and know it good.

In this blog I will cover one part of the security concepts

This topic may include: describe Business Units; describe Microsoft Dynamics CRM security features; describe privileges and access levels

I have found 3 blog posts which I often find my way to when searching for CRM Security.  So I would recommend you go through those because they will give you a good idea how security roles work in CRM 2013, links to them can be found in the blog post below.

To learn about security and business units the best way is to get into your CRM trial and try adding business units and security roles.

First have a good look

second get in there and add some new business units and security roles

thirdly get renaming and deleting them

I will run through this in the video but I recommend you do it yourself, this will help cement the knowledge into your brain and provide more paths to the information (which means you will be able to recall it easier in the exam, yippee).  The blog post and the video work together, the video shows you security roles and business units in CRM and the blog post is a succinct summary of it.

 

I am only going to skip through what I think are the vital points, I expect you to read the three blog posts below, watch my video explanation and have a play in your CRM trial

I will first start with this great table from the power objects blog, this is a good introduction to security

http://www.powerobjects.com/blog/2014/02/14/microsoft-dynamics-crm-2013-business-units-and-data-silos/

 

To help understand how this works, consider the following definitions of the Dynamics CRM security components:

Component Description
Business Unit A scoping mechanism that defines a grouping of users for security modeling purposes; business units are hierarchical in nature. Business Units are a framework upon which a security model is built.
Security Role A collection of privileges (that are given a name) that reflect common user roles of your organization and/or business units; security roles are assigned to users or owner teams. See below for more details on Security Roles.
Privilege (access rights) The definition of a specific type of data access or action that can be granted as a right; privileges are granted through a security role and are cumulative. The following Privileges that can be assigned:

  1. Create
  2. Read
  3. Write
  4. Delete
  5. Append
  6. Append To
  7. Assign
  8. Share
Access Level While the Privilege defines the type of data access, the Access Level defines exactly to which records the privileges apply. You can assign the Access Levels of:

  1. None
  2. User
  3. Business Unit
  4. Parent: Child Business Unit
  5. Organization

For example, if you assign Read privileges to a Security Role at the Access Level of “Business Unit”, users with that Security Role will only have the privileges to see records owned by a user within their Business Unit.

Business Units

As you can see the security in CRM is created from a few pieces of functionality working together.  You have business units and security roles, within these you have privileges and access levels.

Access level controls what the user can see(read)/edit

Privilege controls what you can do to the entity

 

It all starts with business units and the Parent Business unit which is also known as the Root business unit, you can think of this as the mother of all business units.

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 = Tree Structure

Business units are used to create a hierarchy and this is in a tree structure.  The Root business unit will be at the top.

Here are two examples of some very simple Business unit structures.  The common way people use business units is geographical or departmental, although you can split up your organisation and business units anyway that suits you.

Here is a geographical structure

business units 2

 

Here is departmental

business units 1

 

You can see from the pictures above that the business units have create a hierarchy and the root business unit is at the top.

 

What can you do to Business Units

Classic certification questions usually revolve around what you can and can’t do in CRM.  Examples of things they will test

You cannot delete or disable the root business unit

you can rename, disable non root business units (e.g. all the other business units)

 

Disabling Business Units

You need to know what happens when you disable a business unit, what happens to all the users who have that business unit as their default business unit?

When you disable a business unit, it also disables all the child business units below it (and thus all the users who those business units as their default business unit).

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.

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.

Deleting Business Units

It’s possible to delete business units (not the root business unit) but you have to clear them up ready to be removed.

Firstly you have to disable the business unit and you can only do this when

you have removed any the child business unit, now you can either disable and delete them or you can re-parent them.  To re-parent a business unit you can select a new parent business unit.

If you re-parent a business unit this will have the effect of removing all the security roles from the users, this is because security roles are inherited and can be different in each business unit.  This will mean all the users in the business unit you are re-parenting will now have no security roles and won’t be able to log into CRM.  This is explained by an excellent comment by CRM MVP Adam Vero (also a CRM Master)

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.

Like all things in CRM, Microsoft recommend you disable business units rather than delete them, the reason being disable business units just like disabled records can be re-enabled but once something is deleted it’s gone forever.

 

Security Roles

Security roles are a vital part of the security in CRM because 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 levels it 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.

 

Default security roles

There are 15 default security roles in CRM, this provide a good basis to start creating your security roles.  The default security roles are all created in the root business unit.

You need to understand how security roles work with business unit, they can be a bit cheeky.  A security role stays in the business unit it is created in and they copy down to any child business units.

The above line is import because 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.

So you should be careful about creating security roles not in the root business unit because this means you will have a security role that doesn’t exist in any parent business units and in particular the default business unit.  Another consideration is only security roles which exist in the root business unit can be added to a solution file.

What I am saying is don’t create security roles not in the root business unit because you cannot export these out and it may cause a bit of headache if you need the parent business units to use the same security role.

User can be assigned any security role which exist in their business unit.

 

Modify, Don’t create security roles

When you set up a new security role there are hundreds of settings you need to setup, there are 8 privileges for each entity.  The quickest and easiest way to do this is to copy an existing role and modify it.

Microsoft recommend you don’t delete the default security roles so you can have them as a reference but once you have a few security roles I personally don’t think it matters but remember the MB2-703 certification is written by Microsoft and they want the answers they are expecting.

 

System Administrator Role is all powerful

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.

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.

 

Security roles Privileges and access levels

At this point I am going to refer you to the excellent blog on security roles written by CRM MVP Richard Knudson, this blog post has 40 comments, which shows you how many people have read it.

I would also say that this part of the CRM security can be tricky to understand but with regards to the exam does not have as many gotcha’s.

http://www.dynamicscrmtrickbag.com/2011/07/20/dynamics-crm-2011-security-roles/

This blog post about understanding access levels and roles is also very useful

http://www.dummies.com/how-to/content/understanding-access-levels-and-roles-in-microsoft.html

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 like

Go Offline

Export to Excel

Publish articles

 

This is a good place to leave security with more to come

I published the video before the blog article and very kindly Adam Vero (CRM MVP and an expert on CRM as he wrote some of the MOC’s on the subject) left me a couple of excellent comments where I got slightly mixed up in the video.

 

When you disable a Business Unit, it disables the BUs below it, that is correct. But it does NOT disable the users in the BU or any of the children. They are prevented from logging on while they are in a disabled BU, but when you re-enable the BU they can. (If it disabled them all then when you re-enabled the BU it would have no way to know which users to re-enable if some were already disabled manually previously).
Reply
 ·

good point, I think you have basically said what I was thinking and meant to say.  I guess it can seem like the users are disabled because they can’t login but you are right because they aren’t disabled but stopped from being able to login.

Great Comment thanks CRM Master.

Notice that when you change the parent business unit of a BU, this is not just changing the position in the hierarchy and therefore changing the impact of the access levels that people have to records in that BU. It will also REMOVE all inherited Security Roles (and rebuild them) – it does not move the roles with it. So at the moment you move it, the users in that BU have no roles other than any that exist directly in that BU (which often is zero, if everything is always created in the root or imported via Solutions). In most cases this means those users just stopped being able to log on, and you’d better remember who had which roles originally. Users may be able to log on if they are a member of a team that has a suitable role, and they have logged on at least once before, but this is an edge case – expect problems with logons when you move a BU.

so changing the parent business unit of a BU can remove all the security roles from the users in that business unit.  I guess this makes sense because it (as you say) has to rebuild the security roles because you are potentially removing all the inherited roles it had.

This is a good point to consider for the CRM exam.  I will include this in my Security role exam cram notes and maybe make a test question on it.

Thanks again Adam, excellent comment.

 

 

 

CRM 2013 – MB2-703 – Customization and Configuration Certification Solution Test Questions

The best way to prepare for an exam, is to take practice questions and test your knowledge with questions in a similar way the exam will.

I have created a YouTube video where I go through the questions and explain the answers, I would definitely recommend watching that for the first time at least

http://youtu.be/JKmvKLxJvfY

So with this in mind I have created some questions for you.

I have also created the questions as slides, which you have seen in the video

Multiple choice questions

http://www.slideshare.net/hoskinator/hosks-mb2703-solution-question

Quickfire Yes/No Questions

http://www.slideshare.net/hoskinator/hosks-solution-quick-fire-question

 

HOSK’S TEST SOLUTION QUESTIONS

 

  1. Which statements are true about solutions?
    1. Saving your changes in a solution is mandatory
    2. It’s possible to export the Default Solution
    3. You cannot create more than 50 solutions
    4. Publisher is a mandatory field on a solution
  2. Which components can be added to a solution
    1. Team
    2. Message
    3. Business Rule
    4. Business Unit
  3. Which components cannot be added to a solution
    1. Subject
    2. Service Endpoint
    3. Goal
    4. Site Map
  4. What is true about solutions
    1. Deleting an unmanaged solutions doesn’t delete the components if there is data for them.
    2. Deleting a managed solutions deletes the components and the data
    3. You can only export the default solution as an unmanaged solution
    4. You can add plug-in assembly to a solution
  5. What is development and not customization or configuration from the list below
    1. Create a plug-in to run on the creation of an account to set reference number
    2. Create a custom entity to hold venue information
    3. Javascript validation on a phone number field
    4. Creating a business rule to disable a field until another field has a value
  6. What is removed when you delete an unmanaged solution in CRM 2013
    1. Just the solution record
    2. The solution record, the components and all the data
    3. The solution record and the components
    4. The solution record, it’s components and dependant components.
  7. What does the Version number show
    1. major.build.minor.revision
    2. major.revision.build.minor
    3. major.minor.revision.build
    4. major.minor.build.revision
  8. you import a managed solution which contains the account entity, you then import an unmanaged solution which also contains the account entity, both solutions change the Account Number field to have a different name, what name is on the account form
    1. Account Number, you cannot change the name of the account number
    2. The name given to Account number in the managed solution
    3. The name given to the Account Number in the unmanaged solution
    4. The name given in the solution which was imported last
  9. Which of the below is true
    1. You cannot export the Default Solution
    2. You can export the Default Solution from CRM OnPremise to CRM Online
    3. You need a special security privilege to import solutions
    4. Unmanaged solutions have to be published
  10. What is false about managed solutions
    1. Managed solutions can only be changed or altered by the publisher
    2. importing a managed solution is automatically published
    3. Managed solutions have versioning, unmanaged solutions do not.
    4. managed solutions are additive, you cannot remove any components by importing a managed solution

 

 

 

Answers

  1. b,d
  2. b,c
  3. a,c
  4. b,c,d
  5. A,C
  6. A
  7. D
  8. D
  9. C, D
  10. C

 

HOSK’S QUICKFIRE QUESTION (YES/NO)

 

  1. Can you export a managed solution
  2. Can you export an unmanaged solution
  3. Can customization and configuration be used and refer to the same components.
  4. The correct format for version is major.minor.revision.build
  5. Subjects can be added to a solution
  6. There is no limit to the number of solutions you can create
  7. The prefix in the publisher is added before schema name for entities, fields
  8. The changes to components when importing an unmanaged solution cannot be undone
  9. Queues can be added to solutions
  10. managed properties are customizable by default
  11. It’s not possible to export  an unmanaged solution
  12. managed solution must be published after importing

answers

  1. false
  2. true
  3. true
  4. false
  5. false
  6. true
  7. true
  8. true
  9. false
  10. true
  11. false
  12. false

 

 

 

CRM 2013 – MB2-703 – Customization and Configuration Certification Solution Exam Cram Notes

Here are the exam cram notes for solutions, I am assuming you have

read my blog post on solutions and you understand how solutions work and the functionality

CRM 2013 – Understanding Solutions and how they work

watched the youtube video running through adding solutions

CRM 2013 – Understanding Solutions and how they work in CRM 2013

The video going through the Solution Exam Cram notes is here

All the study notes for the MB2-703 exam can be found on the page link above or clicking the link below

https://crmbusiness.wordpress.com/mb2-703-crm-2013-customization-and-configuration-certification/

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 Ribbon

  2. Article Template

  3. Business Rule

  4. Chart

  5. Connection Role

  6. Contract Template

  7. Dashboard

  8. Email Template

  9. Entity

  10. Entity Relationship

  11. Field

  12. Field Security Profile

  13. Form

  14. Mail Merge Template

  15. Message

  16. Option Set

  17. Plug-in Assembly

  18. Process

  19. Report

  20. Sdk Message Processing Step

  21. Security Role

  22. Service Endpoint

  23. Site Map

  24. 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.

    • hosk_newField

    • 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 changes in 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.