Dynamics CRM 2013 (Orion)

The trigger for this post is the about to be released Dynamics CRM 2013 (Orion). As a person involved with customization and software development for Dynamics CRM since version 1.2, I've seen the process repeat itself.  Solutions for Dynamics CRM, have to be fully or partially rewritten, when new version is released. True, not each application needs to be rewritten, but how can you sell a solution developed for CRM 4 when CRM 2011 uses different web services, and Silverlight replaces aspx pages?  How can you honestly offer customers a solution based on functionality that is not available in CRM 4, when it is now available in CRM 2011? We had to rewrite a complete CRM solution that “mimics” activities in CRM 4, to allow billing customers based on completed activities, when CRM 2011 comes with the feature to customise activities, and we only had to add the billing functionality to customised activities.

Rewriting or continuously updating software applications to be fully compatible with new CRM versions, requires software programmers that otherwise can write additional features for the current version. With new versions released, on average, every two- three years, your return on investment is diminishing. When Dynamics CRM 2011 was released we decided to outsource CRM software development using freelancing websites. It was disappointing working with unreliable freelancers or agencies that claim to have CRM knowledge, while most of their staff are “freshers” (software programmers with no experience) with very limited knowledge of Dynamics CRM.

Developing software applications in India has two main benefits:

• India offers competent software engineers, at a fraction of the cost of similar programmers in the US, UK, and Australia.
• Developing solutions for CRM is not as complicated as developing standalone applications, if you deal with a company whose core business is Dynamics CRM and the programmers working for the company have the required experience and knowledge of CRM and CRM SDK.

With this goal in mind, we established Dynamics Objects (www.DynamicsObjects.com), offering Dynamics CRM users and ISV companies software development services in India.

Dynamics Objects is a joint venture between Ask-Distribution (Australia) and Indian company to provide customers with the best of both worlds, great software design at 50-60% less in software development cost. Cost of offshore work in India is substantially lower than that in the US and Europe. At Dynamics Objects, we work 24x7x365 with access to large pool of young, remarkably talented and enthusiastic IT engineers. Solutions for Dynamics CRM is our business. This is our core business and expertise; we only develop software for Dynamics CRM.

Among our customers you will find end-users as well as ISV and CRM resellers. When we are provided with well defined scope and all requirements are clear, we offer fixed prices to develop the solution, with guaranteed on-time delivery.  We guarantee the protection of your intellectual property, design, and development specifications. Software source code is mostly written in C# programming language and provided to you as Visual Studio Solution and CRM unmanaged Solution.

If you need a workflow, form customization, or complex application integrated with Dynamics CRM, use this form to contact us and we will respond ASAP.

How to configure Field Level Security in Microsoft Dynamics CRM 2011

In Microsoft Dynamics CRM 2011 and Online you can use field level security to configure security roles that control user and team access rights to specific fields and entities. In this post, we will discuss how to configure field-level security in Microsoft Dynamics CRM.

A Bit of Background

Before we start, we should define what we mean by security roles and establish a few assumptions. In this context we are referring to the following:

• Action that can be performed (Create, Read, Write, Delete, Share, Assign)
• Object the action can be performed on (User/Team Owned, BU or Organisation Level)

These permissions are granted at the entity level and it is possible that certain fields of the entity contain more sensitive data than the others.

The scope of the field level security is global and is applicable to all data access requests including the following:

• Data access requests from within the web application
• Web service calls using CRM SDK (plug-ins, custom workflow activities and custom code)
• Reporting (using FilteredViews)
• Auditing

Field level security is available for custom fields of custom and system entities.

Implementation of Field Security

There are two high-level steps to implement field-level security:

1. Mark field as a secure field (enable it to be secure); and
2. Configure Security Profiles

Security Profile

Field level security is managed by the security profiles; only secure fields are available for configurations.

A Security profile determines the following:

• Permissions to the secure fields
• Users and Teams

A Security Profile can be configured to grant the following permissions at the field level to the added users or teams:

• Read (read-only access to the field’s data)
• Create (users or teams in this profile can add data to this field when creating a record)
• Update (users or teams in this profile can update the field’s data after it has been created)

A combination of these three permissions can be configured to determine the user privileges for a specific data field.

Step-by-Step Guide to Configuring Field Level Security

Consider the scenario that there is a custom field on the contact form named “Mobile Number (of Top Management)” as in the image below.

The requirement is to make this field secure and configure the security profiles to grant access to the specific teams as listed below.

Team	Access
Sales Staff	No Access
Managers	Read-Only Access
Vice Presidents	Full Access

Step 1

The first step is to mark the field as a secure field, go to the field properties and enableField Security.

Save and publish the changes.

Step 2

Verify that the Field Security has been enabled; open the contact form and you will now see a key symbol with the label of the field. This indicates that the “Mobile Number” is a secure field.

Step 3

The next step is to configure the security profiles.

Create three new Security Profiles with the following configurations:

Security Profile	Added Team(s)
Sales Staff	Sales Staff Team
Managers	Managers Team
Vice Presidents	Vice Presidents Team

Step 4

Configure Field Security for each profile.

Sales Staff
No Access to Mobile Number

Save Changes and Verify

After configuring the “Sales Staff” security profile, the members of the “Sales Staff Team” will not be able to see the data in the secure field.

Managers
Read-Only Access to Mobile Number

Save Changes and Verify

After configuring the “Managers” security profile, the members of the “Managers Team” will only see the read-only view of the data in the secure field.

Vice Presidents
Full Access to Mobile Number

Save Changes and Verify

After configuring the “Vice Presidents” security profile, the members of the “Vice Presidents Team” will have full access to the data in the secure field.

There you have it, some simple steps to configure basic field level security in Microsoft Dynamics CRM 2011.

Related posts: