New features in CRM 2011 as part of Update Rollup 5

1

Dialog Enhancements

Earlier

Now

Added Support for Date and Lookup fields.

Earlier

Now

Support for contextual URL.

Charts

Earlier

Now

Adding Series and Category.

Send email activity

Earlier

Now

Option for Inserting Hyperlink

Auditing

Earlier

Now

Audit User Access

http://msdn.microsoft.com/en-us/library/hh547392.aspx

Improvements in Duplicate Detections

Get the complete detail here

http://blogs.msdn.com/b/crminthefield/archive/2011/10/26/podcast-and-overview-microsoft-dynamics-crm-2011-update-rollup-5.aspx

Hope this helps.

Activity Feeds in CRM 2011 – New features.

2

Hi,

Let us see what all features are there in the Activity Feeds.

  • Download Activity Feeds solution from the market place.
  • Import the managed solution MicrosoftCRMActivityFeeds.zip.

We can see a new link added above Dashboard in “My Work” area

The other place it appears is the Sales area.

Let us go to Settings:-

There we see two new entries: – Activity Feeds Configuration and Activity Feeds Rules.

Let us create a new Activity Feeds Configuration (Post Configurations) record.

For Entity Name, we need to enter the schema name of our entity and we can also select the check box that enables walls for those entity records.

After saving the record the two new rules “New lead created” and “A lead has been qualified” automatically gets added to the record.

A small alert in the record also informs us to publish the related entity, so let us publish the lead entity.

No opening our lead record shows a new Record Wall link in the information section.

Clicking on Follow adds the user as the follower

Now let us qualify the lead record, which is one of the activity feed rule that got auto created.

Going back to “What’s New” link shows us that information in our wall.

Now let us open the same lead record, activate it and submit a post or “Share an insight

This information would also appear in our “What’s New” wall.

We can also add comments in our lead record.

Now suppose I open another lead record and start following it. And now I change something in that record, and then check my wall.

Here I won’t see any update in my wall. This is because of the rule that was defined in the “Post Configuration”

Only when the rule is qualified the update would be available.

Can we define a new rule over there?

It seems that we can only activate or deactivate rule, we can’t add a new one.

Now let us check if we can define Post Configuration for a custom entity or not?

I created a new post configuration record for my custom map entity.

After publishing the entity and opening one of its records I can see the Record Wall link for it.

Now let us check what kind of updates can I receive for my custom entity, as there are no out of the box rules created for it while creating post configuration record for it.

Say I deactivate a map record and then check my wall. I don’t see any update over there which is expected as no rules are defined.

Suppose I write something on Record’s Wall and post it.

It should be available on my wall.

As expected it is.

Similar to records we can also follow system user entity. The post configuration record for the System User automatically got created.

Now let us check the other option Activity Feeds Rules in our system settings.

It contains the feed rules which automatically got created when we defined the Post Configuration rule on lead entity. And again we can only activate and deactivate rules from here; we can’t create a new one.

The What’s new page also shows

auto posts :- the post based on rule.

user posts :- the post on record’s wall.

Clicking on “2 leads” link opens up a view showing the leads records I follow

The edit button gives up an option to upload the profile picture

To summarize,

  • Acitvity Feeds can be enabled for both system entities and custom entities.
  • For certain system entities, Activity Feed Rules will get auto created. We can’t add our own rules, only activate or deactivate them.
  • We can follow records and users. We will receive both auto posts and user posts in our wall (“What’s New” area)
  • We can comment on posts on our wall and delete them.
  • We can set a profile picture.

Changes in System Setting in CRM 2011.

1

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.

GENERAL TAB:-

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.

CALENDAR:-

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.

FORMAT:-


No change here.

AUDITING:-

From here we can enable auditing for the system. This feature was not there in CRM 4.0.


E-MAIL:-

CRM 4:-


CRM 2011:-


The new feature is setting option for Use Smart Matching. It is very nicely explained here

http://mscrmspot.blogspot.com/2011/05/crm-e-mail-setting-deep-dive.html

MARKETING:-

No changes in CRM 2011.


CUSTOMIZATION:-

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.

OUTLOOK:-

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.


REPORTING:-

No changes in Reporting tab


GOALS:-

Goals is a new feature in CRM 2011.


Check this wonderful post on system settings:-

http://www.avanadeblog.com/xrm/2010/12/crm-2011-feature-of-the-week-system-systems-whats-new.html

Hope it helps.

Field Security in CRM 2011 – New Features.

2

Hi,

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

http://weblogs.asp.net/gayanperera/archive/2010/11/02/crm-2011-field-level-security-for-oob-attributes.aspx

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

  • It has System Administrator user account added by default.
  • Has all the field permission set to Yes for all security enabled fields.

  • Any user or team with System Administrator role automatically gets added here, and these automatically added user or team cannot be removed. However it can have other users or team also added to it, which can be removed.

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.

Data Audit (Auditing) in CRM 2011 – New Features.

6

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?

  1. Changes to security roles:-

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

  1. Changes to Shared Privileges of a record:-

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


  1. Audit changes at attribute, entity and organization level: -

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.

  1. Deletion of Audit logs:-

Let us delete audit log from Audit Log Management, and check the audit summary view. It is being logged.

  1. N: N association or disassociation of the records:-

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.