Understanding Xrm.Page Object Model

Xrm.Page Namespace

When writing form scripts, we will interact with objects from the Xrm.Page namespace to perform the following actions:

Get/Set attribute values.
Show/Hide user interface elements.
Reference multiple controls per attribute.
Access multiple forms per entity.
Manipulate form navigation items.

Xrm.Page Object Hierarchy

Context – Provides methods to retrieve information specific to an organization, a user, or parameters that were passed to a form as a query string.

Data – Provides access to the entity data and methods to manage data in the form.

UI – Contains methods to retrieve information about the user interface, in addition to collections for several sub components of the form.

Execution Context

When you register a function for an event handler, CRM lets you pass the execution context object as the first parameter to the function.

This object contains methods that allow you to managed variables you wish to share with other event handlers.

Collections

attributes:

Page.data.entity.attributes collection provides access to each entity attribute that is available on the form. Only those attributes that correspond to fields added on the form are available.

controls:

controls provides access to each control on the form.
controls provide access to each control that have more than one control for an attribute available on the form.
controls provides a collection of controls found in a section.

items:
Page.ui.navigation.items collection provides access to navigation items that are defined using the navigation area of the form editor.

items:

If multiple forms are associated with an entity, each form can be associated with a security role and if security roles of a user enable users to see more than one form, they can select from a collection of Xrm.Page.ui.formSelector.items. A form definition is available in this case.

tabs:

Page.ui.tabs provides access to collection of each of the tabs present on the form.

sections:

A tab can be organized by using more than one section. The tab sections collection provides access to these sections.

Hope this overview was helpful to you!

Fundamentals of JavaScript CRM Customization

August 6, 2014 priyeshwagh777 Customizations crm javascript, javascript customization, microsoft dynamics, ms dynamics crm

JavaScript form customization is a way to interact with entity forms by using JavaScript that is executed for events that occur on the form.

JavaScript form customizations is one of many options to control business processes.

An advantage of JavaScript Form programming is that they are immediate and doesn’t need data to be submitted.

Frequent tasks performed by using form programming are:

Data Validation.
Automation.
Process enhancement and enforcement.

USE FIELD AND FORM EVENTS

Scripts can be added on events like

OnLoad

OnSave

OnChange

Whereas, tabs have the event

TabStateChange

and IFRAMES have an event called

OnReadyStateComplete

EVENTS

OnLoad Event

OnLoad event occurs after the form has loaded. onLoad event is used to prepare the data in the form for use.

OnSave Event

OnSave event occurs when a form is saved. It does not correspond to standard HTML OnSubmit event. The OnSave event occurs in the following scenarios:

When a user clicks on the save button at the bottom right corner of the screen.
Code executes the Page.data.entity.save method, even when there is no changed data to be saved.
The user navigates away from the page and there is unsaved data to be saved.
When auto-save is enabled, 30 seconds after the data has been changed and there is unsaved data on the form.
Code executes the Page.data.save and even if there is unsaved data on the form.
Code executes the Page.data.refresh method passing true as the first parameter and there is unsaved data on the form.

OnChange Event

OnChange is available for every field. OnChange event requires two conditions to be true:

The data in the field must change.
The field must lose focus.

There is an exception to the Two-Option (Boolean) fields. OnChange event occurs immediately when the value is changed without requiring to lose focus.

The OnChange event does not occur if the field is changed programmatically using the setValue method. Instead fireOnChange method can be used in code to trigger OnChange event.

TabStateChangeEvent Event

This event occurs when a tab is expanded or collapsed.

This event is important in the case that you want to use script to modify the src property of an IFRAME control.

OnReadyStateComplete Event

This event is fired when contents of an IFRAME have completed loading.

STEPS TO ADD JAVASCRIPT AS A WEB RESOURCE AND APPLY FORM CUSTOMIZATIONS

JavaScript files for form customization are applied as a Web Resource.
Navigate to Settings > Customizations > Customize the System. Then navigate to Web Resources under Components on the left navigation pane of the Default Solution (Default solution here is used as an example).

In order to add a JavaScript file, we need to create a new Web Resource.

A new JavaScript file could be uploaded or JavaScript code could be simply written in the Text Editor provided by CRM’s Web Resource.

So this way, a new Web Resource of type JavaScript could be created which then can be consumed on CRM Forms for customization purposes.
For registering events on OnLoad events, select Form Properties on the form.

In Form Properties, Select the form libraries that we want to enable on the form level as shown below.

In the above example, a library called ‘new_sampleScript’ has been included. We can now add Event Listeners (which are the functions in that library) that we want to trigger when the library is loaded.

In the above dialog box, select the library which has the desired javascript file/code.

Enter the name of the function you want to trigger on this event.

As shown above, OnLoad events could be executed using JavaScript.

Similarly,

OnSave event listeners could be bound by simply changing the Event to OnSave as shown below.

For OnChange events, the Field Properties need to be changed. Steps to do so are as follows:

Navigate to the desired field and select its properties.

Follow the steps as illustrated for OnSave and OnLoad events above.
So JavaScript code registered OnChange will get triggered when the field value changes and when the field loses focus (Remember, data needn’t be saved for OnChange events to be fired).

Hope this is useful! 🙂

Security Roles in CRM

July 31, 2014 priyeshwagh777 Features in Dynamics CRM 2013 ms dynamics crm 2013, security roles in crm

Understanding the Security Model

Security model has been defined into the Dynamics CRM that protects data integrity, privacy and provides efficient data access and collaboration.
Restricts users from unauthorized access and shows what a particular user must see depending on their roles/privileges.
Does not let a user access records not owned by them.
Also supports data sharing so that records can be viewed by users though they don’t own it themselves.

Three major areas of security model in CRM are as follows:

Role Based Security
Record Based Security
Field level security

Role Based Security

Role based security defines a set of privileges that can be assigned to a user in a form of a role.

A user must be assigned to at least one such role.

Roles can also be assigned to teams in Dynamics CRM 2013.

Roles

MS Dynamics CRM has 14 predefined roles which are defined to match security best-practice of providing only what’s necessary to a particular type of user in the organization.

Custom roles can, however, be created.

Each role is associated with a set of privileges.

One or more roles can be assigned to a user or team.

Creating a new role with intent to assigning a privilege is recommended than modifying an existing role. Roles at user level can’t be modified.

Privileges

A privilege is a permission to perform an action. There are 580+ privileges predefined during setup. Privileges are built-in to the product.

Privileges cannot be added, modified or deleted. However, new roles can be defined to use the predefined set of privileges.

The platform checks for privileges and rejects any operation on which the required privilege is not found.

Privilege is combined with a depth and access level.

Access Level

Access level defines the depth at which a user can access a particular entity type in the organization.

The access levels defined are as follows:

Global (Organization)

This level gives a user access to all records. User with this level automatically have all the levels Deep, Local and User as well.

Deep (Parent: Child Business Unit)

This access level gives a user access to records in user’s business unit and all business units subordinate to the user’s business unit.

Local (Business Unit)

This access level gives access to records in the user’s business unit. Usually assigned to managers with authority over the business unit.

Basic (User)

This access level gives a user access to records he/she owns, objects that are shared with them and objects that are shared with the team which a user is a member of.

None

No access is provided.

Record Based Security

It is the security provided to individual records. It is provided by using access rights.

Access rights are provided after privileges have taken effect. A user may not be able to access a record even if he/she has access granted but does not have Read privileges on that entity the record is in.

Access Rights

The access rights provided are as follows:

Read, Write, Assign, Append, Append To, Share, Delete.

Create Access – Create Access in this does not apply to an individual record. It applies to a class of Entities. Create is handled as privilege. A user who creates a record has all the privileges to that record unless any other access right forbids it.

Sharing Records

Sharing lets user give other users/teams access to a specific record. Useful for sharing information with roles that have only Basic access level.

Sharing capabilities provided are as follows:

Share

Sharing a record with another user holds providing access rights to another user for the record which is being shared.

GrantAccessRequest is used to share a record with another user/team. When a record is being shared with a user, indicate what access rights you wish to grant to that user.

Records should be shared with users who have privilege for that particular entity type.

Modify Share

Rights granted to a user after sharing a record can be modified as well. ModifyAccessRequest is used to carry out this task.

Remove Share

If you share a record with another user/team, you can stop sharing the same. RevokeAccessRequest is used to carry out this operation.

Sharing and Inheritance

If a parent record is created, the sharing properties with the parent record is assigned to the child record.

Child record also maintains its own sharing properties.

Assigning Records

Assign Records means handing over the ownership of a record to another user. The original user then loses ownership of that record.

The system administrator can decide whether or not, should the assigned record be shared with its previous owner.

If ShareWithPreviousOwner is selected, then the previous owner has all access rights to the assigned record.

Dependencies between Access Rights

Security dependencies exist between access rights because a user needs more than one access right to access a particular record.

Create – CREATE & READ are required.

Share – SHARE & READ is required.

Assign – ASSIGN, WRITE & READ is required.

Append – READ & APPEND is required.

AppendTo – READ & APPENDTO is required.

Field Level Security

In field level security, access to high-impact business fields is restricted.

For 2013 release of CRM, field security can be applied to custom fields only.

The following steps are carried out to restrict access to a field:

Create a field security profile.
Associate users/ teams with profile.
Add specific field permissions such as Create, Update or Read to the profile.

System Administrator field security profile gives access to all secured fields. This profile is system managed and cannot be deleted or modified.

There are basically 3 restrictions that can be added in Field Security Profiles once created. They are:

Allow Read
Specifies if users should be able to read information from this field.
Allow Create

Specifies if a user can add information to this field after it has been created.

AllowUpdate

Specifies if a user can edit information from this field.

How secured fields behave for Retrieve and RetrieveMultiple

When Retrieve and RetrieveMultiple are used, CRM check user’s access rights for each record and secured fields. If a user doesn’t have access to secured fields, no exception is thrown but null values are retrieved for secured fields.

If the retrieved data has an access field and user is not impersonated to access it, the user is returned null. A null retrieved by the absence of data and a null retrieved due to lack for privilege can’t be distinguished.

Also, if the secured field is in the filter criteria, a null is substituted for the actual value of the filter criteria.

Following is the justification of how secured fields behave in different scenarios:

Filtered Views
Filtered view will not return data for secured fields if user is not impersonated with proper access rights to the field.
Records are shared

A user can only give access to another user of the access that they themselves have. The user or team members with whom the record was shared now have that type of secured access field only on the shared secured fields on only that particular record, even if the user to whom it was shared does not have field security profiles that give them access.

Create or Update.

If a user does not have required impersonation on the required secured field while calling Create or Update methods, an exception is thrown.

Hope this was helpful! 🙂

Custom Workflow Assembly

July 31, 2014July 31, 2014 priyeshwagh777 Features in Dynamics CRM 2013 custom activities, custom workflow assembly, ms dynamics crm 2013

What are Custom Workflow Activities?

Custom Workflow Activities can be added to an existing workflow to provide additional functionality in Workflows in CRM.
Workflow Assemblies are included in steps of a workflow designer where input parameters can be provided to the same to carry out its designated functionality.
Required Assemblies are Xrm.Sdk and Microsoft.Xrm.Sdk.Workflow
Custom Workflow Activities can be written by deriving CodeActivity class in your workflow assembly.

Custom Workflow Activities have Input and Output parameters that take and give out data to the workflows.
protected override void Execute(CodeActivityContext context){ //Activity code} needs to be initialized to add functionality to a Workflow Assembly.

Registering a Custom Workflow Assembly.

Custom Workflow Activities are registered in Plugin Registration Tool.
They are not registered on a particular entity or on any message, like a Plugin.
Registered Custom Workflow Assemblies then appear in the workflow step designer.
We can specify the Name of the workflow and the WorkflowActivityGroupName in the Plugin Registration Tool as shown below.

Input and Output Parameters of a Workflow Assembly.

Here is an example of how we can declare an input parameter to a custom workflow assembly as follows:

A default value can be provided along with declaring the Argument.
Same way, we can add Output parameters to the custom workflow assembly as below.

Or even declaring the Argument as both, input and output argument which is as follows:

Attributes and Microsoft Dynamics CRM Types.

Bool
DateTime
Decimal
Double
EntityReference
Int
Money
OptionSetValue
String

So, that was a short and quick introduction about Custom Workflow Assembly! Hope this is helpful. 🙂

Dialogs in Dynamics CRM 2013

July 28, 2014July 31, 2014 priyeshwagh777 Features in Dynamics CRM 2013 dialogs in crm 2013, dynamics crm 2013, process dialogs in crm 2013

Introduction

Dialogs are a collection of pages which contains a set of Prompts and Responses.
Dialogs are synchronous.
Dialogs need to be initialized by the user using the CRM Online system.
Requires user input at stages to run to completion. Much like a wizard.

Components of a Dialog

Page:

It is a basic unit of a dialog. More like a visual container. Usually there are multiple pages in a Dialog that guide the user through a process to get certain tasks done.
Each page can have multiple prompts and responses.

Prompt & Responses:

A Prompt asks a question to the end user and captures response.

Response has a data type that is provided in order to specify what input should be fetched by the system. They are:

None – No response is required. Used for introductory purposes.
Single Line – A single line of text, integer or float values. A textbox is displayed to fetch this.
Radio button – Predefined responses shown to select only 1 among them.
Picklist – A drop down menu.
Multi-Line of text – Multiple lines of text input is supported.
Date and Time – Date & Time input used like in CRM forms.
Date Only – only date can be selected.
Lookup – Specifies an entity record.

The user response for each Prompt and Response step is stored as a step variable, and can be used later in the dialog flow.

Static and dynamic hyperlinks can also be added. For static hyperlinks, you need to specify the full URL. Dynamic hyperlinks, however, can be used in any text field. These hyperlinks refer to an entity record in CRM.

Tips help in specifying information for each prompt and response that helps the user in responding to the prompt. Tips are optional.

Input Arguments and Variables

Two more important components in Dialogs.

Input Arguments

Input Arguments are used to pass data between parent and child dialogs.
Input Arguments are defined for the child dialogs and data is passed onto them. This is linked by adding a Link Child Dialog step in the parent dialog. And then, the required responses can be mapped with the input arguments in the child dialog.
Simple arithmetic and string operations can be carried out by using Assign Value.
Default value for input arguments must be specified while declaring them.

Variable

Variables allow us to store intermediate values such as strings or computed values.
Intermediate values are responses that are gathered along the run of a dialog.
These variables are stored respective Prompt and Response

Comments

Comments are the notes that appear at the bottom of a dialog that are displayed during the run of the dialog.

Limitations

A link child dialog cannot be an intermediate step.

Number of nested steps in a child dialog is limited. Depends on the browser in use. Because these nested steps in browser are nested tables.

There are a few workarounds for nested steps limitations in case they happen to gray out:

Redesign the dialog to use fewer nested steps.
Add a child dialog to reduce the number of steps in parent dialog.
Use a different browser.

Actions that can be taken on Dialogs

Dialog Related Activities

These activities were first introduced in MS Dynamics CRM 2013 and are available as steps in MS Dynamics Process Designer.

Query CRM Data

Enables us to define query variables that can be used to query CRM data. These query variables can either have pre-defined values or can be parameterized so that they accept values at runtime.

We can parameterize a query variable by using ModifyQueryVariables tab on the Define Query page, and then use the dynamics section on the query form to associate the prompt and response variables with the query variables.

Query Variable defined using the Query CRM Data is available for all prompts and responses from the point where they have been defined in the dialog definition.

Assign values

Allows simple arithmetic operations like increment, decrement and multiply and string concatenation operations on the input variables.

Can also be used to clear any values that is stored in the variables or input parameters.

Link Child Dialog

A dialog can be specified as a child dialog and then can be invoked from other dialog which will be its parent dialog.

Stop Dialog

Enables to end a dialog at a particular stage. Can also be used in conditions where we need to stop the dialog.

Workflow related activities

Workflow related activities like Create Record, Update Record, Delete Record, AssignRecord, Send e-mail, start child workflow and change status.

Start a dialog using a URL

An activated dialog can be started using the following URL format:

http://CRMServer_Name/Org_Name/cs/dialog/rundialog.aspx?DialogId=DialogID&EntityName=EntityLogicalName&ObjectId=EntityObjectId

where,

CRMServer_Name is the name of your CRM server.

Org_Name is the organization name

DialogId is the GUID of the dialog you want to run.

EntityLogicalName is the Entity Logical Name of the Primary Entity of the dialog you want to run.

EntityObjectId is the GUID of the primary entity record.

An example of the same is as follows:

http://crmserver/AdventureWorksCycle/cs/dialog/rundialog.aspx?DialogId=9F53D2D8-AC54-46A6-A190-F23DE6677C65&EntityName=contact&ObjectId=41D1884E-B4B6-DF11-BF5E-00155DB05986

Conclusion

Dialogs enable us to trigger guided process. Input parameters and variables can be manipulated with during the process and also fetches CRM data. Dialogs are user interactive processes which prompts for messages and requests and fetches responses to be used in the processes.

SiteMap Customization in CRM 2013

July 28, 2014July 31, 2014 priyeshwagh777 Customizations ms dynamics crm 2013, navigation pane in dynamics crm, sitemap, sitemap customization

What is a SiteMap?

The SiteMap is a node in the xml file of an exported unmanaged solution.
Navigation using SiteMap is evaluated with our Security Privileges to access a particular Entity in order to display it in the Navigation Menu.
If security privilege does not let us ‘Read’ a particular entity which is in the sitemap, the navigation item is not displayed.

Editing the customizations.xml file

The file can be fetched from an exported unmanaged solution.
We can edit this by using even a simple text editor. But it is recommended that it should be edited in a proper XML schema validator tools.
To reflect the changes, import the updated file back in the CRM. In case of any errors, CRM won’t let it get imported and the error message will be shown.

Components of the Navigation Pane

There are default areas on the navigation bar consisting of SFA (SALES), CS (SERVICE), MA (MARKETING), Settings (SETTING), and HLP (HELP).

Once an area is selected, it comes besides the main Microsoft Dynamics CRM button. And hovering over that shows a menu that appears at the bottom. This menu contains the subareas divided into different groups.

Configuration options available using SiteMap

Edit Labels

The text displayed is default sitemap uses ResourceId attribute to specify the text. This attribute, however, should not be changed or removed.
We can use <Titles> (SiteMap) or <Title> (SiteMap) elements instead to specify the txt we want to use for the organization/solution.
Title elements will override ResourceId attribute values.

Add/Change Icons

<Area> (SiteMap) and <SubArea> (SiteMap) has a 16×16 icon that is displayed on the navigation. PNG, GIF, JPG image web resource are supported.
While including the image as a web resource, use ‘$webresource’ directive. This will create a dependency and the web resource will not be deleted until the SiteMap element uses it.

Add/remove elements

Copy pasting existing XML elements is recommended as it helps reduce writing erroneous code.
In case of removal of elements, the fact that whether changing the security privileges will serve the purpose should be considered.
It is recommended to use security privileges to an area/subarea instead of removing elements.

Group Links within Areas

<Group> (SiteMap) is used to create groups. For this, <Title> (SiteMap) and <Description> (SiteMap) is used for it to be displayed as a group.
Then, edit <Area> (SiteMap) element to add the ShowGroups attribute to True.

Adding New pages to an Area.

We can also include Web pages in the navigation bar. For that, <SubArea> (SiteMap) must be used in order to add new pages to an area.
To display a custom page in the application, use Url attribute instead of Entity This Url should contain the directive ‘$webresource:’ followed by the location of the HTML web resource. As discussed earlier, using the web resource directive will prevent it from being deleted by forming a dependency. So that it is available whenever the SiteMap requires it.

Manually Editing the SiteMap

The SiteMap firstly needs to be added into the unmanaged solution. This can be done by navigating to Settings > Customizations > Solutions. Then, in Client Extensions, include the SiteMap.
Save the solution and chose to export the solution. A zip file will be downloaded. By extracting its contents, find xml file. SiteMap can be edited using this file.
Find <SiteMap> tag to edit the SiteMap.
Create a new zip file, include the extracted solution with the edited xml file.
In Solutions in CRM 2013, include the zip by choosing it to import as a solution. Finally, publish the customizations and refresh the page to see the modifications.

IMPORTANT

Encode the Ampersand Character.

When there is an ‘&’ in the URL used in the SiteMap, replace it with “&”. Without this, the XML validation fails and the solution will not be imported.

Example from SDK 2013:

Correct:

Incorrect:

Errors while importing SiteMap

The import tool takes care of the XML validation. In case of any errors, the default SiteMap is updated and an error message is thrown. In this case, we must rectify the errors and re import the solution.

XML Elements used in SiteMap

<Area> (SiteMap)

Contains the Areas which appear on the CRM 2013 Navigation Pane.

The syntax is as follows:

<Area URL=”” Id=”” ShowGroups= true|false>

<Titles><Descriptions><Groups>

</Area>

The attributes are as follows:

DescriptionResourceID – For internal use only.

Icon – A 16×16 resolution image that is shown in the button.

Id – unique identifier in ASCII. Spaces are not allowed.

ResourceId – for internal use only.

ShowGroups – Boolean value to choose whether groups of sub-areas are shown in the navigation pane.

Title – Deprecated. Use <Titles> (SiteMap) and <Title> (SiteMap).

Url – Specifies the CRM for Outlook URL to render for the Outlook folder that represents the Area.

Child Elements – <Titles> (SiteMap), <Descriptions> (SiteMap), <Group> (SiteMap)

Parent Elements – <SiteMap> (SiteMap) – root node.

<SiteMap> (SiteMap)

Defines the root node of the SiteMap used for Navigation.

The syntax is as follows:

</SiteMap>

The attributes are as follows:

Url – Specifies the URL for CRM for Outlook to render.

Child Elements- <Area> (SiteMap)

Parent Element- <SiteMap> (ImportExportXml) the container node for <SiteMap> node within the customization.xml file.

<Titles> (SiteMap)

Specifies a set of localizable titles for the parent element.

No attributes are present for this element.

Child Element – Specifies the text in a specific language to be displayed for the parent of the Titles element.

Parent Elements – <Area> (SiteMap), <Group> (SiteMap), <SubArea> (SiteMap).

<Descriptions> (SiteMap)

Specifies a set of localizable descriptions for the parent element.

No attributes are present for this element.

Child Element- <Description> (SiteMap)

Parent Element – <Area> (SiteMap), <Group> (SiteMap), <SubArea> (SiteMap)

<Title> (SiteMap)

Provides a title in a specified language for the parent element i.e. <Titles> (SiteMap)

The syntax is as follows:

The attributes are as follows:

LCID – 4 or 5 digit Locale ID for a title.

Title – Text to be displayed.

No child elements exists for this tag.

Parent Elements- <Titles> (SiteMap)

<Description> (SiteMap)

Provides a description in a specified language for the parent element i.e. <Descriptions> (SiteMap) element.

The syntax is as follows:

The attributes are as follows:

LCID – 4 or 5 digit Locale ID for a description.

Description – Text to be displayed.

No child elements exists for this tag.

Parent Elements- <Descriptions> (SiteMap)

<SubArea> (SiteMap)

Specifies a navigation option within an <Area> (SiteMap). It defines objects that will be displayed under the selected application.

<SubArea

AvailableOffline=[“0”|”1”|”true”|”false”]

CheckExtensionProperty=””

Client = [“All” | “Outlook” | “OutlookLaptopClient” | “OutlookWorkstationClient” | “Web”]

DescriptionResourceId=”” Entity=”” GetStartedPanePath=”” GetStartedPanePathAdmin=”” GetStartedPanePathAdminOutlook=”” GetStartedPanePathOutlook=”” Icon=”” Id=”” License=”” OutlookShortcutIcon=”” PassParams=[“0” | “1” | “true” | “false”]

ResourceId=”” Sku=[“All” | “OnPremise” | “Live” | “SPLA”] Title=”” Url=””>

</SubArea>

The attributes are as follows:

AvailableOffline – Whether SubArea is available offline.

CheckExtensionProperty – Internal use only.

Client – Default. Mulitple specified values can be used.

DescriptionResourceId – Internal use only.

DefaultDashboard – Specifies the GUID of the default dashboard.

Entity – Specifies the value of an Entity.

Icon – Consists of an 18×18 icon image.

Id- Unique identifier.

OutlookShortcutIcon – Specifies the outlook icon used.

PassParams – Specifies whether the organization information and language context passed to the URL.

ResourceId – For internal use only.

Sku – Specifies the versions of MS Dynamics CRM that displays this SubArea.

Url – Specifies a URL of a web resource to display in the main frame of the application when this subarea is selected.

Child Elements- <Privilege> (SiteMap)

Parent Elements – <Group> (SiteMap)

<Group> (SiteMap)

Holds a group of SubAreas

The syntax is as follows:

</Group>

The attributes are as follows:

DescriptionResourceId – For internal use only.

Icon – Unused.

Id- Unique identifier.

IsProfile – Controls whether this Group represents a user selectable Profile for the workplace.

ResourceId – For internal use.

Url- URL to render for the Outlook folder that represents the Group in CRM for Outlook.

Child Elements – <Descriptions> (SiteMap), <SubArea> (SiteMap), <Titles> (SiteMap)

Parent Elements – <Area> (SiteMap)

<Privilege> (SiteMap)

Controls whether a subarea displayed based on privileges available in any security role assigned to a user.

The attributes available are as follows:

Entity- Specifies the entity to check the privileges for.

Privilege – Privilege to check.

No child elements are present.

Parent Elements – <SubArea> (SiteMap)

Pass Parameters to a URL Using SiteMap

We can pass organization information and language context of the user and the language context of the organization for the target application by using PassParams attribute of the <SubArea> (SiteMap)

Parameter-

orgname – Organization Name

userlcid – User Language Code. eg. 1033 for English

orglcid – Organization language code. Eg. 1033 for English.

Without Parameters –

http://myserver/mypage.aspx

With Parameters –

http://myserver/mypage.aspx?orgname=AdventureWorksCycle&userlcid=1033&orglcid=1033

Conclusion

SiteMap Customizations are carried out with the basic requirement to show the navigation pane in a customized manner to user who have different access privileges to different CRM data.

Hope it helps!

Duplicate Detection in CRM 2013

July 21, 2014July 21, 2014 priyeshwagh777 Features in Dynamics CRM 2013 Detection, duplicate detection in crm, duplicate records, ms dynamics crm 2013

What is Duplicate Detection feature?

In order to maintain integrity in data in our system, it is a good practice to reduce duplicate data. To do so, MS Dynamics CRM provides facility to do so.
Duplicate Detection needs to be enabled from Settings > Data Management > Duplicate Detection Settings.
Default duplicate detection rules are defined for accounts, contacts and leads but not for other types of records. To enable duplicate detection on other types of records, we need to create new rules.

Enable Duplicate Detection

We can enable Duplicate Detection for our organization under Settings > Data Management > Duplicate Detection Settings as shown below.

As shown above, Duplicate Detection first needs to be enabled organization wide.
Then we can chose on what the duplicate detection should be enabled.
1. When a record is created or updated.
2. When the CRM for outlook goes from offline to online and,
3. During data import

Duplicate Detection Rules

There are predefined rules already available in Duplicate Detection Rules for account, lead and contact.

Likewise we can create new rules of our own with certain criteria to run of other types of records. In order to create new rules, select New.
For the new Duplicate Detection Rule, give a suitable name. Set Base Record Type to the entity you want the duplicate detection rule to run on. And provide Matching Record Type to compare the record to for the rule to run.

We can optionally chose to compare with having the Case-Sensitivity and to Exclude inactive matching records.
In the above example, we want to detect duplicate records with same customer name being created on Employee. So, we’ll set the criteria for our rule to run the duplicate detection.

In the example above we have 2 criteria for the duplicate detection rule to run. These criteria are ANDed i.e. both should satisfy to detect duplicate records successfully.
First, we are comparing the Name for its exact match and then we are checking the Address for its first 5 characters to be the same.
We can also optionally chose to ignore blank values. In this case, we are not doing so.
Once done, we can Save and Close the duplicate detection rule.
So, our newly created rule appears in the list of Duplicate Detection Rules. It hasn’t been published yet. So it won’t detect duplicated unless we Publish it.

To do so, select the rule we just created, and Publish it.
Let’s check the duplicate detection rule we just published.
Now, We have 2 records in employees Andrew and Samuel. We shall try to create another employee named Samuel with same address to force CRM to detect a duplicate on creation of a new Employee record.
On saving this record, CRM will throw a warning that it detected duplicate of the record that we are trying to create.

So here, it has detected a duplicate records that matched the rule we created for name and address of the Employee. If we want the duplicate record to be created nonetheless, we can click on Save to do so.
Cancelling it will avoid the duplicate record being created and we can go back to our record to change it before it is saved.

Hope it helps you! 🙂

Another post on Duplicate Detection jobs is coming up soon. Will update you once done. Keep checking this area. Thanks!

Access Teams in CRM 2013

June 30, 2014July 21, 2014 priyeshwagh777 Features in Dynamics CRM 2013 access teams in crm 2013, ms dynamics crm 2013

What are Access Teams?

Access Teams are light-weight teams aimed at high volume sharing scenarios.
These are designed to address the concerns of the overhead of calculating security roles when needed.
Access Teams can be automatically created and managed.
Access teams can’t be granted security roles and they can’t own records.
They only access records through sharing.
Sharing privileges are defined by an access team template. They don’t change dynamically for existing records if the template changes.
Access Teams can’t be used as resources in Service Scheduling.

Access Teams, however, can be created manually through Teams interface in Settings > Administration.

Creating an Access team

An Access Team first needs to be enabled from an Entity level. To do so, navigate to Customizations > (Entity). We can consider an example of a custom entity, say Customer.

The checkbox on Access Teams needs to be checked to be able to enable Access Teams for Customer entity.

Then, we navigate to Settings > Administration > Access Team Templates. And select New template.

Give a meaningful Name to the template that will be identified. Select the entity from the Entity dropdown that we enabled Access Teams for at the Entity level.

We can provide desired access rights as mentioned above from Delete, Append, Append To, Assign, Share, Read and Write.

Now you Access Team template has been created. Next, we shall add a sub-grid to the Customer form that will access this template. And Set Properties as follows for the Sub-Grid on the form.

As shown below, set the following properties for the Data Source of the sub-grid,

Records to All Record Types

Entity to Users
Default View to Associated Record Team Members

And

Team Template to Customer List Access (This is the Access Team Template you just created)

The sub-grid now is set to add users to the Access Team that will use the access rights we set in the Access Team Template.

Once the record is created, you can add Users to the sub-grid that will have access to that particular record and which will have access rights as defined in the template.

As in the above form, the 2 users have access to the record with name Ashwin V. with the access rights Append, Append To, Read and Write.

How Access Teams work?

Whenever Access Teams are enabled for an entity, the team’s lifecycle is managed automatically.
So when the first member is added to the Access Team grid, an access team is created and the first member is granted the access rights as specified.
Then as members are added and removed, access to those members are added and removed respectively.
When the final member of the access team is removed, the team gets deleted. This marks the end of the Access Team lifecycle.
Deactivating the record, however, won’t affect the access team. Only adding and removing members from the access team will cause deletion of automatically generated access team.

Viewing the Access Teams

In normal operation, access teams are created automatically. Hence, they are system generated and are deliberately hidden from users.
In order to view these access teams, use ‘Advanced Find’ option to query for Teams of type Access and Is System Managed as Yes, No.
This will show both access teams, automatically created and system generated as shown in the figure below.

The automatically generated access teams are named as their GUID.

Migrating to Access Teams

Teams that have been migrated from older version will be migrated as owner teams. It’s possible to convert them to access teams under the following conditions:

The owner team doesn’t have any security roles, and
The owner team isn’t the owner of any records.

The CONVERT TO ACCESS TEAM button will convert the owner team into an access team once the above said criteria is matched.

Programmatic control of access teams

Remember, an access team is actually created when we add the first member to the access team. So we need an existing team to add a team member to it.
A new SDK message is introduced to handle this scenario. AddUserToRecordTeamRequest.
Using the said SDK message, we need to specify the record and team template that the user should be added to. This will resolve the request to the access team that is relevant and, if necessary, create the team before adding the user as a member.
When working with system generated access teams, this message should be considered for adding users as team members.

So, that’s it! Hope you find this useful. 🙂

D365 Demystified

A closer look at Microsoft Dynamics 365.

Year: 2014

Understanding Xrm.Page Object Model

Fundamentals of JavaScript CRM Customization

Security Roles in CRM

Custom Workflow Assembly

Dialogs in Dynamics CRM 2013

SiteMap Customization in CRM 2013

Duplicate Detection in CRM 2013

Access Teams in CRM 2013

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: