Tip on Required Fields – Forms v. BFP

Required fields behave differently on Dynamics 365 Forms as that of on the Business Process Flow. Especially when you have ‘Disabled’ them.

On Forms –

Once you have disabled a required field on the Form, the Save action ignores the same and lets you save the record.

onForm

For obvious reasons, the required field on the BPF is ignored when you save the record on the form with all required fields filled in.

 

On BPF –

The required field cannot be ignored to move the Business Process Flow to the next stage!

onBPF

 

You’ll discover this soon. Hope this helped. 🙂

Quick Tip: Cleaning Queue Items

So are you stuck with email queue that has junk of emails you don’t want? And maybe those emails are important to CRM.

Let’s say you have these emails in your Queue (imagine there are a lot many and removing them seems like a big task)

qItems.PNG

Here’s what to do:

  1. Run a Bulk Delete Job on the following:
    Queue Item entity and the required criteria you want (maybe you want to delete only old Queue Item which you no longer need to convert to other record types)
    bulkDeleteCriteria.PNG
  2. And submit the job.

Now, even if you delete the Queue Items, the Emails will still remain in CRM in Activities records and those are not lost!

Hope this was helpful! 🙂

Shared Mailbox in Office 365

Now often, you want to have a common mail address for everyone within a team to monitor and interact through like info@domain.com or support@domain.com

Office 365 provides this capability with something called as Shared Mailbox.

Features of Shared Mailbox

  1. Shared Mailbox doesn’t need an Exchange license.
  2. Shared Mailbox doesn’t have its own credentials. Users add this mailbox to theirs and use their own credentials to access it.
  3. Shared Calendar is available in a Shared Mailbox where everyone can see who is available when

 

Setting up Shared Mailbox

  1. You’ll need to be an administrator in Office 365 to be able to create a Shared Mailbox. Navigate to Office 365 Admin Center and find Shared Mailboxes options under Groups.
    optionInO365
  2. Click on Add a mailbox addMailboxButton.png
  3. I’ll call it Sales@domain.com, for example. And click Add.
    mailboxCreated.png
  4. Shared mailbox gets created within moments!
    mailboxInView.png

 

Adding Users to the Shared Mailbox

Only users who have an Exchange Online license can be added to Shared Mailboxes.

  1. Click on the mailbox and then on Edit in Members area to add O365 users to the mailbox as shown below
    mailboxDetails.png
  2. Click on +Add Members to add users to the mailbox
    addMembers.png
  3. You’ll find all the members who already have an Exchange Online license are eligible for adding to the shared mailbox.
    eligibleMembers
  4. I selected both the users seen in above step to add to the Shared Mailbox.
  5. Those members are seen on the detail pane of the selected Shared Mailbox as shown below
    membersAdded.png

    Adding Shared Mailbox to Outlook

    I will the OWA example in this blog to show how to add the shared mailbox to the user’s Outlook

    1. Let’s assume we have the mailbox pwagh@cft79.onmicrosoft.com and we want to add the shared mailbox sales@cft79.onmicrosoft.com to pwagh’s mailbox.
    2. In OWA, right click on the root folder of the mailbox and click on Add shared folder
      addMailboxToOutlook.png
    3. Start typing the name of the Shared Mailbox and it should auto-populate the same for you. Select the Shared Mailbox and click Add.
    4. The mailbox should then appear in your OWA.
      mailboxAddedToOutlook.png

    Note: It takes a few minutes until the Shared Mailbox is accessible from your mailbox after adding it

     

    Hope this was helpful.

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:

  1. Get/Set attribute values.
  2. Show/Hide user interface elements.
  3. Reference multiple controls per attribute.
  4. Access multiple forms per entity.
  5. 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.
xrm.PageObjectModel

 

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:

  1. 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:

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

 

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

 

  1. 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:

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

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:

  1. Data Validation.
  2. Automation.
  3. 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:

  1. When a user clicks on the save button at the bottom right corner of the screen.
  2. Code executes the Page.data.entity.save method, even when there is no changed data to be saved.
  3. The user navigates away from the page and there is unsaved data to be saved.
  4. When auto-save is enabled, 30 seconds after the data has been changed and there is unsaved data on the form.
  5. Code executes the Page.data.save and even if there is unsaved data on the form.
  6. 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:

  1. The data in the field must change.
  2. 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).

addWebResource

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

newWebResource

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.

formProperties

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

addEventHandler

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.

 

handlerProperties

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.

changeEvent

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

  1. Navigate to the desired field and select its properties.

fieldProperties

  1. Follow the steps as illustrated for OnSave and OnLoad events above.
  2. 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

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:

  1. Role Based Security
  2. Record Based Security
  3. 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

accessLevel

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:

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

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

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

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

  1. 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:

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

 

  1. Modify Share

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

 

  1. 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:

  1. Create a field security profile.
  2. Associate users/ teams with profile.
  3. 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:

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

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

  1. AllowUpdate

Specifies if a user can edit information from this field.

editFieldSecurity

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:

 

  1. Filtered Views
    Filtered view will not return data for secured fields if user is not impersonated with proper access rights to the field.
  2. 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.

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

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.

class

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

registerAssembly

 

 

 

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:

dateTimeIP

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

moneyIP

 

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

intIP

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