I am currently working on a project that deals with queue management and the following posts were of immense help
Thanks to the author !
I happen to came across these two good resource for someone preparing for the customization and application exam of CRM 2011.
Found these two wonderful articles that explains Team Ownership and Reparent feature in depth
Do check them out !
Firt get the Id of the button using IE Developer Tool and then use display property to hide it
var btnRunWorklfow=top.document.getElementById("new_student|NoRelationship|Form|Mscrm.Form.new_student.RunWorkflow-Large"); btnRunWorklfow.style.display='none';
Suppose we have an html page having an iframe that shows a crm record. If we want to access the attributes on the form or call the save function from our html page, we can do it in the following manner.
var crmForm =document.getElementById("myIframe").contentWindow.document.getElementById("contentIFrame").document.frames.document.forms['crmForm']; var XrmPage =document.getElementById("myIframe").contentWindow.document.getElementById("contentIFrame").document.frames.Xrm.Page;
Hope it helps.
Just created a simple html page to see how we can use it in CRM 2011.
The page is on account form and shows name of the account. It also accesses ClientGlobalContext.js file to show contextual information like Organization Unique Name and User Id of the user.
The html page:-
Points to remember
Access the ClientGlobanContext js file
src=”ClientGlobalContext.js.aspx” if the html web resource doesn’t follow any folder structure
src=”../ClientGlobalContext.js.aspx” if the html web resource follows folder structure
and using window.parent.Xrm.Page to get the reference to the Xrm.Page from the html web resource
Hope it helps.
Today I cleared my first CRM 2011 certification exam. It had total 75 questions and duration was of 140 minutes.
One thing different from CRM 4.0 or CRM 3.0 exams was that the in the case of multiple choice questions, there were no “select 2” or “select 3” correct answers, it was “Select all that apply”. In some cases i think there was only one correct answer for “Select all that apply” questions.
Well, talking about topics, there were more than 15 – 20 questions on Solutions only, especially managed solution and managed properties followed by around 10 questions on Audit and Field Security. Then few around new features in Business Unit, Teams and Security Roles.
Go through the helpful tips given here
And following is the link to the posts that I used as notes while preparing for the exam.
Hope it helps.
The number of tabs has increased from 7 to 10 in CRM 2011 from CRM 4.Preview post
The new tabs added are
Calendar, Auditing and Goals.
Now let’s first start with the General Tab and options therein.
There are two more options added in CRM 2011 in General tab are
The Get Started Pane in CRM 2011.
IM Presence can be set from General system settings.
If we try saving an appointment record with duration more than 10 days we get the warning that “duration of the appointment is invalid”
There was no such option in CRM 4.0.
No change here.
From here we can enable auditing for the system. This feature was not there in CRM 4.0.
The new feature is setting option for Use Smart Matching. It is very nicely explained here
No changes in CRM 2011.
In CRM 4
We could set the Prefix here in CRM 4, now this option has moved to Solutions where we can define prefix for Publisher of the solution.
Custom menus and toolbars: – This can be governed through RibbonDiffXml for entities and Application Ribbon for the application.
In CRM 2011, the only option is of Application mode.
Things are same for CRM 4 and CRM 2011, the only new option in CRM 2011 is whether user sees get the outlook client message in the Message bar or not.
No changes in Reporting tab
Goals is a new feature in CRM 2011.
Check this wonderful post on system settings:-
Hope it helps.
Field Security in a new out the box feature in CRM 2011. The most important thing to know about it is that Field Security doesn’t work on out of the box attributes. It only supports custom attributes on system entity or custom entity.
Let us open one of the out of the box fields on Contact entity from customization area.
As we can see the radio buttons for Field Security are disabled. However there is some unsupported way to get that enabled for out of the box attributes
Let us create a custom field named “Password” (text) in our contact entity and enable field level security for it.
Dragging it to the form shows a “key” symbol beside it.
If a user with System Administrator role opens the record, he would be able to view, add a value and update the value for the password field.
If a user with role other than system administrator opens the same record, this is what he gets to see
The field level security is governed through Field Security Profiles.
Opening Field Security Profiles we can see that the System Administrator is already added over there.
If we try to delete it, we get the following error message.
We can add users and teams to security profile.
The specific points to remember about the System Administrator Security Profile are following
“Users who do not have the System Administrator Security Role have no permissions on secured fields unless the users are added to a Field Security Profile (either directly or through team membership). Any user who has no permissions on a secured field will still be able to see the field on a form or in field selection lists for a view, but will not be able to see or change the data in the field. On a form, the field will appear with dots in place of any data.”
Talking about field permission, there are three field level permissions.
Read, Update and Create. They are independent of each other i.e. it is not necessary to have read permission to have update permission.
To understand it more clearly let us create new security field profile named “Test Security Profile”, add a user (test user) other than System Administrator to it. By default the field permissions would be set as No.
Let us edit it and set Read as Yes.
Now on opening the contact record with the test user who has been added to this profile, we can see the following changes now
The value of the password field is visible to the user. But it is disabled so can’t be edited. It remains disabled in case of new record as well.
What if we set Yes for Allow Update and No for Read and Create?
In that case, the field appears blank but it is editable.
If we update the field with some value, after save the field again goes blank.
However for the System Admin user we can see the updated value.
Now let us look at how Field Security and Security Roles apply.
Suppose user A has read access to records of a particular Entity record, and then we create a Security Profile that has Read and Update set as Yes for a particular field for that entity and add the user A to it. Here User A would not be able to edit the field because of the restriction put by Security Role.
One thing to remember is that through Field Security Profiles we won’t be able to increase the access of user then what he has got through his security role.
Suppose user A shares a record with user B and gives him Read access. The user B is also part of a security profile that gives him read and update access on a particular field for that entity’s record. Here the User B will be able to see the value of that particular field as he has been given Read access by user A through sharing but he won’t be able to update it.
There is one more thing we should be aware of i.e. Sharing Secured Fields just like sharing records.
We can add user or team with whom we want to share the secured fields. Here we can only set Read and Update, no Create because to Shared Fields apply for Shared Records which are already created.
By share secured fields, permissions granted through sharing can be selectively reduced for secured fields.
“Connie shares a contact record with Patricia. The share permissions are read and write. Patricia also has read and update permissions on a custom field in the entity. When Patricia views the form for the record, she finds she can change the custom field. Connie then adds an entry in Share Secured Fields for the record that grants Patricia only read access to the custom field. Now when Patricia views the form, she cannot update the custom field. It also allows permissions to be increased over those granted through Field Security Profiles” (from Microsoft’s CRM 2011 training material)
It also allows permissions to be increased over those granted through Field Security.
“Jose shares a record with Chris, granting read and write share permissions. Chris has no access to a secured field through any Field Security Profiles. When Chris views the record in the form, he cannot change the value of the secured field. Jose then adds an entry for Share Secured Fields granting Chris update permissions on the secured field. Chris can now change the value of the secured field on the record.” (from Microsoft’s CRM 2011 training material)
A record does not have to be shared with a user in order to grant shared secured field permissions.
The permissions required to share fields can be set on the Business Management tab of the Security Role under Field Sharing.
Hope it helps.
Let us take an example,
Suppose we have created a new organization and we want to enable auditing on “Topic” field of Lead what do we need to do here?
First to enable auditing let us open the field for customization.
There we can see that it is already enabled for auditing. However below we have warning icon that tells us that “This field will not be audited until you enable audition on the entity”.
That means we need to first enable it for our lead entity. So let us open our lead entity for customization.
For the entity it is not enabled by default, we need to check the Auditing checkbox to enable it. However there we again see a message below that asks us to enable auditing for the organization first.
On checking the Auditing checkbox,
we get a note over there that tells us that by default auditing will get enabled for all the fields.
But we want auditing for only the topic field, and obviously we are not going to open each field and disable auditing there. So what can we do here?
Here we can select all the fields from our customization area and click on edit button to open the dialog box that will allow us to bulk edit the customization information for them.
So let us first disable it for all fields and then select those fields for which we want to enable it. Remember to click on Next to select all the fields on each page and disable them.
While doing so we might get this error
What it means is that Auditing cannot be set for some fields. (Not Applicable)
Following are the fields in lead entity to which audit is not applicable
Mostly it would be GUID fields, fields internally used by CRM, CreatedOn, ModifiedOn etc.
Now let us go back and enable Auditing system wide,
Check Start Auditing and Click Ok button to close the dialog.
Now let us change the topic field in our lead record and check its audit history. (From the left navigation pane of the record’s form)
Apart from change in the name of the topic we can see one more record in our Audit History that shows when the Audit was enabled for the Entity.
Right now we saw record level auditing, we can also see the system wide auditing. For this we need to go to “Audit Summary View”
Opening the record will give us more detail
Now I log in with another user having Sales Person role,
I don’t see Audit History link on left navigation pane.
And from settings, I get the message the I don’t have enough permissions.
So here we have four permissions related to auditing.
We understand Audit History and Audit Summary, let us check Audit Partitions, for this click on Audit Log Management.
Here each audit log stores audit records for one calendar quarter. If we try to delete log with serial number 2, we get the following message
i.e. only the oldest partition can be deleted, the current active partition cannot be deleted.
Now the question is what all things we can audit apart from change in the record’s field?
I have enabled auditing on Security Roles entity, and now I go and change the Access Level of Sales Person role on View Audit History privilege. So that should be tracked now…
Now as the Security Role entity doesn’t have a form similar to our other entities, I expect to see the audit for it in “Audit Summary View”. Let us open it.
It does have record for our access level change, let us open it
Ok so now I opened a lead record and shared it with the other user, so that should be audited?
Yes it is there. Let us open it
Now let us try disabling audit for the entity, and open the audit history
It says that entity/attribute audit has stopped; now let us open the last Share log
So by disabling the audit we will lose our old information as well.
Let us delete audit log from Audit Log Management, and check the audit summary view. It is being logged.
Let us create a new N-N relationship between lead entity and one of our custom entities (name G), and then associate there records. We can see one entry in our Audit History for that event.
On opening the record we can get the details.
Here as we have not enabled auditing on the G Entity (our custom entity) we won’t see any audit information there in its Audit History link.
Now let us find out what happens in the case of 1-N relationship.
For this delete the existing N-N relationship between lead and custom entity, and create a new N-1 relationship between lead and the custom entity g. so that our custom entity appears as a lookup in lead entity.
Now let us open any of the lead record and set value for our lookup there.
On doing so we can see a new event update being added to our audit history.
However we can’t see old value new value there as we have not enabled that field for auditing. So let us open that field from customization area and enable auditing for it and change the lookup value in the lead entity.
Now if we update the lookup we can see the old value and new value both.
Hope it helps.