This is my first blog about the stages of beginning a new job. I am constantly learning and developing new skills which makes every day unique and exciting. As I’m undergoing this learning process I often think to myself, how can I facilitate this learning process? and how can I be the best I can possibly be?

Key Points within this Blog

On the first day I was gifted a book “The 7 Habits of Highly Effective People”. This book has set foundations, planted ideas and ethics to develop my character and essentially facilitate the massive learning process that I’m currently undergoing. As I’m reading the book I am constantly making connections between the traits of an ‘effective person’ and the quest of striving to be the best person and employee I possibly can be. Here are some key points from the book that really stuck out to me, there are no shortcuts when learning and always strive to bring an inside-out approach. I will delve into why these specific topics relate to myself and how they could potentially enhance or develop character with others who are entering a new environment. 

Shortcuts are Temporary Fixes

To really know the inside out of a subject, there is a sequential learning process. There is no point in skipping steps when learning a subject because each step is important and each step will allow you to have a better understanding of the overall subject. Skipping steps while learning will ultimately not allow you to master the subject. Taking shortcuts seem to be the easy way out and apply ‘quick fixes’. This information really struck me from the book, to master something it requires time and sequential growth. As I’m learning new processes at work I occasionally found myself overlooking small steps to move onto the large components or larger steps in fulfilling my role as an employee. I quickly realised with the help of the book and my own experiences that this is the wrong approach. Leaving out these smalls steps may create a feeling of learning the subject faster and efficiently but this is untrue. This will result in problems in the future because it is likely one of these small steps will have to be faced in the future or will just leave a gap in your overall understanding of the subject.

An Example of Why Shortcuts are Temporary Fixes

For example, when playing basketball if you have watched the game and have a somewhat okay understanding of the game then practicing your lay-ups or jump shots may seem like an extremely effective way of quickly becoming a good player and making a good team. This would seem true initially but what if you don’t know all the rules? You feel as though you know the important rules but not all of them. You’ve left out a ‘small step’ in developing your over all game. When playing in the final minutes of a trial game for a great team you are down by one point and you make a 3 second offensive violation, resulting in a turnover. You did not know about this rule because you decided to skip a small step and just learn the seemingly ‘important’ steps. This small but important rule resulted in a devastating turnover and potentially cost your team the loss. This example shows how creating shortcuts can make you believe that you’re developing your understanding of a subject efficiently. However, leaving out small components can result in extremely negative outcomes.

What is an Inside-Out Approach?

Firstly, it is important to understand what exactly an inside-out approach is. An inside-out approach begins within one’s self and developing oneself internally to impact and influence outgoing relationships in a positive manner. I learnt a lot of this while reading “The 7 Habits of Highly Effective People” as it explains in high detail the importance of an inside-out approach in any given situation.
When entering a new environment, it is important to bring the right attitude, work ethic and motivation to mold in and to produce good results. What I have recently learnt is, that bringing an inside-out approach helps to produce good results and builds strong relationships.

Why Should You Bring an Inside-Out Approach to a New Environment?

Relating to entering a new environment, any new environment, it is highly important to have this inside-out approach to ensure that one’s self can develop and grow to positively influence and impact others within the environment.  This can be done by the way one thinks and acts in this new environment. Instead of dwelling on things that one can’t change and wishing these things would change or get better, one should make actions that they can change to make the environment a better place not only for themselves but also others.

Applying this Approach to My New Situation/Environment

If I want to learn within this job and this field, then I have to be the kind of person who brings enthusiasm and curiosity every day. This is a gradual process and takes time and patience. If I don’t understand something I can’t simply blame the tutorial for it not explaining it in a way that I understand. It is up to me to go beyond the tutorials and provided information. This is bringing an inside-out approach and is extremely important in any given situation.

Why would I Want to Do This?

This last week I’ve been experimenting with more of the features present in Dynamics 365. I ran across an issue when I was creating an Event Management scenario.

A brief overview of my scenario: A company wanted to manage multiple events, which contacts can register for. Seems like a fairly standard N:N relationship. One small issue. Native many to many relationships in Dynamics 365 do not have the ability to store attributes on the relationships.

Why is this an issue? Say for example, I want to track the amount of tickets that each contact requires, and retain this value to perform operations against the event (reduce total capacity to prevent overbooking etc.). I might want to track whether or not a contact has any dietary restrictions, or special considerations for a particular event but not for others. All of these would be most appropriately stored as an attribute of the relationship itself, and not of either the contact or the event.

An Overview of the Desired Relationship

Basically, what we are wanting is for the relationship itself to be able to track and maintain these attributes, so that the event is able to maintain these values, and the ability to distinguish their source.

How Do We Accomplish This?

In order to accomplish this, we’ll need to instead of creating a native N:N relationship between the Contact and Event entities, create two 1:N relationships with an intermediate entity which stores the data that we wish to retain. This consists of a 1:N relationship from the Event entity to the Registration entity, and a 1:N relationship from the Contact entity to the Registration entity. This allows for a contact to be related to multiple registrations, and multiple registrations to be related to a singular event, allowing the same sort of relationship between the Contact and Event entities as a native N:N relationship. Now to implement the functionality.

For our purposes, let’s create an entity called ‘Registration’ which manages the registration of the contact to the event. When creating this entity, we can add any number of these attributes that we require.

To actually implement the 1:N relationships is very simple. In your solution, navigate to the endpoints of the N:N relationship (in this case, the Contact and Event entities), select the 1:N Relationships section, and create a ‘New 1-to-Many Relationship’. As the related entity of the related entity, select the previously created intermediate entity - in this case, the Registration entity. This will create a lookup on the related entity (this will need to be added to the related entity’s form), which can be used to select the primary entity.

By making the lookup field required on the intermediate entity, the intermediate entity will always contain a reference to the N:N endpoints. In our example, registrations (and their corresponding contacts) will be accessible from the Event entity, as well as the corresponding relationship attributes. Sub grids can be used to display records, and rollup fields are an excellent choice for displaying additional information, such as: Number of tickets purchased, Number of attendees, etc.
 

This blog is going to help the reader to create workflows with the best, most desirable structure. This will allow the workflow to be easily readable, modifiable, and shows the user when their workflow stops or has errors specifically within the workflow.

To show the best practices while creating a workflow I am going to show an example of a workflow. The workflow will consist of; when an account is created with the address as “Christchurch” and when the Main Phone field contains data, call the account owner, and wait until the account owner has been contacted then assign a task. This will easily show the reader how to create a structured workflow.

Example: Undesirable Structure for a Workflow (Nested Check Conditions)

Example: Desirable Structure for a Workflow (Easily Editable Conditions)

Stopping the Workflow and Notifying Where it has Been Stopped

The first key point when structuring a workflow is to have the check condition (if statement) state: “If (Condition) does not satisfy a constraint” then “Stop the Workflow”. The reasoning why this is desirable is that it shows exactly where the work flow fails or stops.  This is shown in the screenshot for: “Desirable Structure for a Workflow”. Also, the user can “Set Properties” for the output in the System jobs section (Settings -> System -> System Jobs).

 
For example, if the account wasn’t from Christchurch, then the workflow would stop at that specific check condition. Assuming that the user set properties for the “Stop workflow with status of:” section then their message would appear in the System Jobs.

Avoiding the Maximum Depth (Max Depth = 5) with Conditions

Another key point when structuring a workflow is that if the check conditions are not nested then the implementer will never reach the maximum depth within an if statement. The maximum depth is at 5 conditions so having the conditions separated (like in the desirable structure) allows the implementer to avoid this.

When one tries to click “Add Step”, they are unable to.

Easily Editable Workflows

The final key point when structuring a workflow is that at a certain point in time, the implementer may not want the workflow to check if the Account is from Christchurch or some other condition. Deleting a step, especially the base step, is extremely frustrating when the conditions are nested. When the conditions are in the desirable structure format then deleting and editing the conditions is extremely simple and will save the implementer a lot of time in the long run. When the conditions are nested the editor has to delete all conditions that fall below the condition they’re trying to delete. In the desirable format it is possible to delete any condition within the workflow without modifying the others.

For those that have just started learning Dynamics CRM, the information presented can be a bit overwhelming at times. Dashboards are a convenient interface to the CRM system, with commonly accessed information available for quick reference, and links in the charts, lists and diagrams providing a quick method to access the source records.

Why Would I Want to Use Custom Dashboards?

There are plenty of reasons to want to create a custom dashboard in Dynamics CRM. You may want to reduce what you see as clutter, or to have all of your commonly accessed views close to hand.

A custom dashboard is a good way to achieve these things, as they can be easily created, edited and updated should the need arise. They can also display custom views, charts, and web content that has been previously defined.

A user may want to customise the dashboard to provide an overview of their workload, or so they may have a view that they access frequently, with custom views that have multiple sort options preconfigured. A user may have a built in dashboard that they like, but don’t use all the features of, and want to reduce some clutter.

An example may be a user who usually uses the built-in Sales Dashboard, but they want to remove the fields that they don’t use, and change some of the data representations that are already part of the dashboard. They usually use the Activities, opportunities and leads areas, and like the visual representation of the sales pipeline that the Open Opportunities graph represents. They don’t tend to use the top customers or active accounts views, so they want to get rid of those and resize the others to fill up the remaining space.

Basing a custom dashboard off a previously existing dashboard is a quick and easy way to create custom dashboards for users.

There are really two avenues of approach here for the general user, creating a new dashboard from scratch or basing one off a pre-existing board.

Creating a New Dashboard From Scratch

Navigate to the module that you’d like to create a new dashboard for – Sales, Service, or Marketing, and select the Dashboard view.

At the top of the view is a series of buttons which allow for actions to be performed on the Dashboard view.

 
To create a new dashboard, click the ‘NEW’ button. This will prompt the following dialogue.

 
This dialogue allows for selecting a layout for your custom dashboard. Which layout you choose will depend on what elements you want to emphasise, but none of these layouts are set in stone. Element size may be modified post creation.

After choosing a layout, you are directed to the ‘Dashboard Canvas’. This section allows for content creation and layout modification. Some of the items that can be included in a dashboard are:

• Charts
• Lists
• Web resources
• iFrames

 
Clicking the quick create button within the component panes themselves will add content of that type to the specified section. Additional content can be added to the layout by either selecting the ‘CHART’, ‘LIST’, ‘WEB RESOURCE’, or ‘IFRAME’ components from the bar at the top. Content added may be of a custom type; if a user has previously used the advanced find feature, and then saved the resulting view, they can then use that view as a component. Similarly, any custom charts can be used. This content is referred to as a ‘component’.

Components can be selected by clicking on them. Once selected, they can be moved by dragging to a different area, resized by clicking the Increase/Decrease Width/Height buttons, or removed by clicking the Remove button situated at the top of the screen that appears when content has been selected.
 
Components in the Dashboard are organized into sections. Sections can be modified by double clicking the grey section pane behind the components, or selecting the section pane then clicking ‘EDIT COMPONENT’.

Finally, the Dashboard itself can be named, which is a required field. Once you have finished adding components to the dashboard, click save to save the dashboard. Any layout components that do not have content do not show up in the final view, instead appearing as blank space.
 
A created dashboard can be edited again by navigating to the dashboard, then selecting edit in the bar at the top of the screen.

Customising an Existing Dashboard

A custom version of any dashboard may be created. Only dashboards that the user has created or has permission to edit may be edited, but custom versions may be created by navigating to the Dashboard you want to customise, and then instead of selecting ‘NEW’ when going to create a dashboard, select ‘SAVE AS’. This option will allow the user to create a copy of the currently selected dashboard and give it a custom name. System dashboards can be customised in this fashion, by creating a copy of the dashboard that the user has permission to edit, then changing the content in that dashboard. Doing so does not change the original dashboard in any way.

This copied dashboard may then be edited in a similar way to above.

Again, content can be modified, removed and resized, allowing for full customisation of these dashboards to purpose.
    

A Few Things to Note

It is important to note that these dashboards are personal, so other users cannot see them by default. Personal dashboards can however be shared to other users and teams.

If you have CRM on a mobile device, and want to be able to access your new dashboard there, you’ll need to make sure that your dashboard has been enabled for mobile devices. To do this, head back to the edit screen for your dashboard, and click the ‘PROPERTIES’ button located at the top of the screen. This should bring up a dashboard properties form. At the bottom of the form should be a checkbox, titled: ‘Enable for mobile’. Make sure this is ticked, save your customisations, and you should have access to your custom dashboard next time you launch CRM on your mobile device.

Dashboards can also be previewed for mobile by clicking the ‘MOBILE CLIENT’ button at the top of the edit screen. Selecting either Tablet or Phone will take you to a preview of the dashboard for your specified device.

Over the last couple of weeks, I’ve been reading The 7 Habits of Highly Effective People – By Stephen R. Covey. In this, Covey talks about the habits and behaviours that lead to being an effective person. The pathway that starts with achieving small, personal victories, and then how this shapes us and allows us to become capable of having effective, fulfilling interactions with others. Or, as he puts it – the private victory followed by the public victory.

In essence, a private victory is mastery over oneself – the journey to becoming independent. Not to say that independence is the end of the road, as truly effective people are interdependent, working with others to achieve something greater than one can achieve by oneself (public victory).

Introspection is the Foundation of Effectiveness

But in order to actually begin on this path, a certain perspective is needed. Who am I? What is my purpose? What do I want to do? Who do I want to be? It’s nigh impossible to act on oneself, to find a path, when you don’t even know where to look. So, introspection.

It’s important to have a strong sense of centre. An unshakable set of principles, something to refer to with each action. A proper evaluation of what is important to us, what we want to achieve and be, can help guide us in these matters. What roles do you see yourself performing? How do you want to be perceived? A full understanding of oneself and ones principles allows one to have a greater sense of comfort and security, an unshakable sense of self. Being comfortable with oneself is the first step to forming strong and meaningful relationships with others, as this allows you open and comfortable when expressing yourself to others.

A New Job, A New Opportunity

A few weeks ago, I started here at Magnetism. I’ve been looking at this new position as a new opportunity, a chance to define new roles for myself, and a chance for introspection; to look at and evaluate what drives me. With this approach, I’ve defined a set of goals for myself and evaluated what success looks like to me. This helps me to be proactive, gives the drive to bring a positive attitude and atmosphere, and work to improve myself all the while.

A new location, situation or position is an opportunity for a new perspective. A change in situation is sometimes exactly what we need. This most recent change has allowed me to re check my list of priorities and refocus on what’s important to me. Moving to a new workplace can be hard, but being equipped with the correct mind-set and motivations is helpful in building strong relationships and setting the foundation for a positive future environment.

What are Child Workflows?

Child workflows are workflows that can be started by another workflow or dialog. They are useful for a number of reasons, but are particularly useful for abstracting logic so that it can be used in different areas, or to isolate a particular process.

To provide an example, take a workflow that manages cases by escalating them after a certain period of time. One child workflow of this may take the responsibility for reassigning the case and notifying the manager of the original owner, while another might create a list of tasks that the new owner should complete and add change the priority of the case.

Why Use a Child Workflow?

Child workflows are a good way of splitting a workflow into more modular pieces. These pieces can be used in multiple locations, but also hold the advantage of ease of modification. Taking the above example, this means that if the required logic for a particular step changes, let’s say the reassignment and notification step, a user may deactivate the child workflow and make changes to it. While the child workflow is deactivated, the master workflow will continue to run, and will wait for the child workflow to be reactivated before calling it. This means that any time the master workflow is triggered and needs to run, it will still run even if the required logic is undergoing maintenance. This is important to note, as if all logic had been contained within the master workflow, any cases that reached the requirement to be escalated within the time that the master workflow was deactivated would never be escalated by that workflow. Child workflows are, in that sense, a safeguard against any scenarios where deactivating the workflow could lead to undesired effects (automatically triggered master workflows etc.).

How to Allow a Workflow to be Run as a Child Workflow

When creating a workflow, in the process editing screen, there is a checkbox which when selected allows the workflow to be run as a child of another process.

Note that if additional triggers are left activated (Start when: Record is created etc.) the workflow will continue to be activated by these triggers.

How to Call a Child Workflow From Another Workflow

A child workflow can be added to another workflow like any other step. Click ‘Add Step’, then ‘Start Child Workflow.

This adds an editable step to your workflow which allows you to select the entity that you want the Child Workflow to run on - this may be a related record, or the record that the primary workflow is running on – and of course, specify the workflow that you want to run on this record.

This step acts like any other step in that it can be placed inside conditions, and other steps can be performed before or after it.

Take care when adding child workflows though, as no error message or prompt is presented if you try and add an inactive workflow. Activating the parent also does not active the child workflow. If you are intending on using the parent workflow, make sure that you activate the child workflow, or the logic will hang as described above.

However, you choose to use cases in Dynamics 365, the use of SLAs is very useful for managing and ensuring all cases are resolved and closed in a timely manner. But, if you ever have to reopen a case for whatever reason the SLA will not automatically be restarted. This means that if your users reopen a case they are not held to any time constraints to resolve it.

Fortunately, there is a simple step that you can take to restart an SLA. To be able to do this you should create your SLA instance setting the Applicable From field to an editable field i.e. a custom field and not the Created On.

When you deactivate a case the SLA is stopped. You can trigger it to restart by updating the date/time of the Applicable From field.

In the image sequence below I show what happens to the SLA associated to a case when a case is deactivated, reactivated and then the Applicable From field is updated manually.

Firstly, the Applicable From field is set to my custom SLA DATE field. (Note once you have saved the SLA you will not be able to change this field). The SLA Detail “Test Case” does not have any conditions so will always be applied to a case where the SLA Date field is set.

The image below shows that the case is active and the custom SLA DATE field is set.

The user resolves the case within the SLA time period, so the SLA was resolved with a status of successful.

After reactivating the case the SLA status remained successful, which shows that the SLA does not automatically restart.

The user then manually updates the SLA DATE field by changing the time by 1 minute. As you can see, the SLA has recalculated.

Instead of manually updating the SLA DATE field, we could have a plugin that sets the field when a Case is resolved, which would also restart the SLA timer.

Composite fields were introduced in Microsoft Dynamics CRM 2013 to combine multiple fields into a single field on the form. It’s a nifty way to display multiple individual fields, which are concatenated into one. The most common application of composite fields is used with the out-of-the-box Full Name and Address fields (e.g. Full Name composite field has individual fields First Name and Last Name). Automating send keys into composite fields can present some interesting behaviours when using Selenium with Microsoft Dynamics CRM.

I simulated automating entering input values into a composite field using the Selenium WebDriver in Microsoft Dynamics CRM 2016. The composite field on the form needs to be clicked first before opening the fly-out menu containing the component individual fields. For example, the Full Name field needs to be clicked first i.e. automate click on element By.Id (“fullname”). This opens the fly-out menu allowing the WebDriver to access elements in the composite field. Initially, I entered values into composite fields for my first name then last name using the WebDriver. From a testing and user perspective, this order is also intuitive and logical based on how it is set up on the CRM form. I got into a bit of a dilemma when I enter values via send keys, as my values do not get sent to the fields using the Actions sequence with Actions.SendKeys().

I experimented with composite field behaviour (manual testing as opposed to automating) by simply clicking the Full Name field to activate the composite field fly-out menu. CRM sets the focus to the first available control (First Name) field. Then, I click outside the fly-out menu once without entering any values into the fields, and CRM sets the focus to the Last Name. I click outside the fly-out menu again, and CRM throws an error because the field Last Name is set to Business Required and there are no values. It appears that the composite field fly-out menu cannot be closed until field Last Name contains a value.

It is standard for Microsoft Dynamics CRM to set the focus to the first available editable control. If required fields also have null values on save, CRM would automatically set the focus on the required fields that are blank. It is commonly encountered when programming JavaScript on the form. With this happening, CRM can override any SetFocus commands that are called in our scripts.

We can tackle this problem by using the default CRM browser behaviour to our advantage. I know from my manual testing that clicking the Full Name puts the focus into First Name. That means that the field First Name is already set to clicked which was initiated by CRM.

We can alter our usual Actions sequence of entering values into fields by removing the actions.Click() step. This way, our test scripts do not throw any exceptions and valid operations are executed as intended. My snippet of code below shows actions.Click() removed from where it is usually found in the Actions sequence of sending keys into a field.

Another obvious work around to this problem without removing the actions.Click() step is by using the normal Action sequence but changing the order in which field to enter the values. Swapping the order in which field to send keys allows the Actions sequence to execute properly. We can do this by sending values first to the Last Name field, then to the First Name field. Here is example code of the following using the usual Actions sequence (encapsulated within my SetFieldValue class). I can reuse the same Actions sequence via EnterText() method with the First Name field without omitting the actions.Click() line.

When automating tests in Microsoft Dynamics CRM using Selenium, it is important to recognise browser behaviours of CRM composite fields and required fields, and how it can force your test scripts to execute differently with unexpected results. By recognizing this, we can work around a fix to how we would automate send keys to composite field elements.

Customizing views is a simple task but it is highly important. Views efficiently display data to the user when they are used correctly. Views are important so the user is able to see all relevant information and they allow the user to select the view that displays the data they need to see, hiding irrelevant data.

Create a Personal View

Go to the entity that you would like to create a personalized view of, click the drop-down arrow next to the current view then select ‘Create Personal View’.

Next, select what conditions and filters you want in your new personalised view (In this case I want to show the restaurants in Christchurch). After this step, select the “Edit Columns” button on the same page.

Here you can personalize your view! And show exactly what you want, and how you want it. In the common tasks section the arrows pointing left and right simply move the selected column accordingly. The configure sorting defines which columns to sort the query by. This may be alphabetically by name or by date. It is possible to sort on multiple conditions. The change properties button allows you to re-size or add a web resource to the selected columns. And the remove button removes the selected column from the advanced find view. For now, click the add columns button.

This will take you to the “Add Columns” pop out, here you choose what to display on your new query. I chose to show the City, Country and some other options below. This is subjective to what you want to display. It is as easy as that!

 
Click “Save As” and name the personalized view. It is important to name the view something that is relevant to the output of your advanced find query.

Share a Personal View

Now that you have your new view, what if you would like to share this with other users or a team? It is extremely easy. You simply click “Saved Views” as seen on screen #2, select your view and click “Share”.

In this next screen, you can simply add and remove a user/team. The toggle all permissions of the selected items will toggle all the read, write, delete, assign, and share permissions on/off of the selected items. Reset removes all User/Team that the view is shared with.

There you have it, how to customize your own personalized views and share with others!

Adding a quick view form onto a Main form in Dynamics 365 is a simple and effective way of displaying information from one entity to another entity. In this demonstration, I will show you how to create a quick view form in the custom entity Venue and display this quick view on the custom entity Event. I have premade the Event entity to have a N:1 relationship to the Venue entity.

The first step is to create a quick view form. This is done in the ‘Form’ section of a specified entity. You simply click “New” -> “Quick View Form”.

The second step is to add the fields you want displayed on the quick view form. I added the “Name”, “Contact”, “Location” and “Phone Number” fields from the field explorer on the right-hand side of the page. Then save and close the quick view.

The final step is to place this quick view onto the form you would like it displayed on, in this demonstration I place the Venue quick view onto the Event entity. The Event entity has some fields already placed on it that I have previously made. I add the quick view by first going to the insert tab and then clicking “Quick View Form”.

 
I add the Venue information to the Event form, giving it a useful name. As shown below.

The final image shows the new quick view form on the Event entity.

In Microsoft Dynamics 365 the creation process when creating a business rule is significantly different, in a good way! The business rules still use programming logic in a more visual and simplistic manner. Business rules are more than just business logic, they are extremely useful, and can be used to lock fields, hide fields and display errors on fields. I will walk through how to create a business rule to ensure that the end date for an event is after the start date, and to display an error message next to the field if it is not.

Creating the business rule

1. Open a solution containing your entity, or customize the default solution.
2. Navigate to the entity that the business rule will be placed on.
3. Then find ‘Business Rules’ beneath the entity.
4. Click new.

Initially there’ll be a condition with no rules applied to it. I then created two rules to be used with an ‘and’ conjunction (Rule Logic) which means they both must be true for an action to occur.

 
Above you can see that the finish date must be less than (before) the start date and that the finish date must contain data. The finish date must contain data so that the error isn’t displayed when no data has been entered in the field. In the red box, there’s a nice view which displays the logic once it has been implemented.
 
Next, there’s an action that occurs when both conditions have been satisfied. In this case an error message is displayed that is shown in the below image. An action can be added to a condition by dragging the action from components to the right of the condition. Adding an action below the condition makes the action an ‘else’ action.

This shows the simplicity when creating business rules in Dynamics 365, it is easy to pick up, edit and implement.

Highlighting over the red X shows the error message.
 

Dialogs are great, but it can be a hassle to show nicely in CRM, especially when activating them via a custom button. With different browsers, browser settings and configurations, opening a dialog may result in the dialog opening in a new tab, or a new window, and doesn’t allow for a consistent user experience.

A great utility for dealing with this issue is a solution called Alert.js. This solution can be found on GitHub: https://github.com/PaulNieuwelaar/alertjs. This solution contains many utilities for creating custom alerts inside Dynamics 365. I’ve experimented with a few of these, but the particular functionality I have been working with is the Alert.showDialogProcess method. Using this allows for opening a dialog in a similar fashion to CRM’s built in alerts and notifications, allowing for a consistent user experience.  

How do you go about using it?

The solution can be downloaded from GitHub and then imported in the solutions section of Dynamics CRM. The documentation is fairly comprehensive, so refer to that for installation guide and usage instructions.

Using Alert.js in conjunction with the Ribbon Workbench

Alert.js can be used in conjunction with Ribbon Workbench to add functionality to custom buttons, allowing for, among other things, the creation of good looking popups, alerts, and displaying dialogs in a manner consistent with CRM’s built in alerts.

For my purposes, I wanted to display a dialog process. Doing this was fairly simple.

1. Create a simple JavaScript function that calls the Alert.js “Alert.showDialogProcess” function. Upload this to CRM as a web resource.
2. Pass through the required parameters
   • dialogId – The Guid of the dialog you wish to display.
   • entityName – The logical/schema name of the entity for which the dialog is being run.
   • recordId – The id of the record from which the dialog is being run. With ribbon workbench, this can be passed as a CRM parameter (‘FirstPrimaryItemId’).
3. Pass through any of the other optional parameters that you wish to configure: dialog height or width, a callback to be run on completion, or the base URL of the CRM server – which may be required in some instances.
4. In Ribbon Workbench, create a new button, and an accompanying command.
5. In the accompanying command, create a new JavaScript action and load in the function you created in step 1. This function usually deals with passing through all parameters but the recordId.
6. Add a new JavaScript action, calling Alert.js with the function isNaN. Shift this above your function in Alert.js. This ensures that the Alert.js library is loaded prior to the function specified in Step 1, so that there are no dependency issues.
   
   
7. Publish changes to solution.

The result is a dialog that uses a style consistent with CRM’s lightbox, allowing for more consistent alerts and processes.

While working with Dynamics CRM’s Record Create and Update Rules we came across this error within a Case creation step:

“The specified contact doesn’t belong to the contact that was specified in the customer field. Remove the value from the contact field, or select a contact associated to the selected customer”.

Our implementation consists of the automatic creation of Cases based on an incoming Email. The requirement was that the sender of the Email (i.e. the From field) and the Customer on the Case should always be set to a Contact and not an Account.

By default, the Case creation rule sets both the Customer and Contact to null(Channel Properties). Consider the following scenario:

• Frosty Stevens is a Contact in CRM. His parent Account is Frosty’s Ice Cream Store

If an Email from Frosty Stevens came into CRM, a Case would be created as follows:

• Customer = Frosty’s Ice Cream Store (Account)
• Contact = Frosty Stevens (Contact)

Because we wanted to force the Customer to always be a Contact, we changed the value from null(Channel Properties) to Sender(Email). Doing this resulted in the Case being created as follows:

• Customer = Frosty Stevens
• Contact = Frosty Stevens

 
This small configuration change caused the Record Creation and Update Rules to fail when creating a Case. Note that the failure only occurs of the parent Account is set on a Contact, otherwise it works fine.

If you come across this error, you have two options.

1. If you are getting the error “The specified contact doesn’t belong to the contact that was specified in the customer field”, use the default values CRM provides under the Actions section of the rule step. NOTE these values can’t be set by a lookup so you must recreate the create step of the rule.
2. These values will not be defaulted if you add the create step in the Specify Other Actions section of the rule. But you will also lose some of the supporting background functionality that you gain by doing your primary action in the Actions section of the rule. For example, the email that triggered the create case step will not have the newly created case set as its regarding field.

Both of these choices have their advantages and disadvantages, so be sure you check you will still maintain all the functionality you require.

When modifying a Microsoft Dynamics 365 solution, you may require functionality that is portable and can be triggered in multiple circumstances. For example, running a rollup field calculation job, which is able to be done from SDK messages, but otherwise cannot be triggered manually out-of-the-box. In this instance, you may require a plugin or a custom workflow activity that calls the SDK message and runs the job. However, if you want to be able to run this from multiple places, a plugin may be more appropriate.

How does this work?

Custom actions were added in Microsoft Dynamics CRM 2013, and provide a fantastic point against which to register plugins. Once actions have been created, it is possible to register a plugin against their schema name, which acts like a custom SDK message that is fired whenever the action is called.
Custom actions can provide the target for a plugin as well as pass values to plugins. This is done by setting input parameters for the custom action and then accessing these using from the plugin execution context.

To register a Plugin against a Custom Action:

1. Navigate to your Solution > Processes > New
   
2. Enter a Process name and select Action as the Category. For the Entity, select the entity for which you want to fire the Plugin. Note that the Process name that you enter will be what you use to refer to the action later when you register the plugin, so pick a name that will make it easy to identify.
    
   
3. Click OK, add any additional steps and functionality you want to the action, then add any input parameters that you need for either your internal steps or for your plugin.
   
4. Create your plugin.
   
5. Register your plugin using the plugin registration tool bundled with the SDK.
   
6. Right click on your plugin in the tool, and select ‘Register New Step’.
   
7. In the Message field, select the custom action you previously created.
   
8. Finish registering step as normal.
   
9. Add action to wherever you want the plugin to run.

Why is this useful?

Custom actions allow for a useful target for plugins to fire in multiple circumstances. For example, while a workflow activity could perform the same functionality, a custom workflow activity can only be called from a workflow or a process, while a custom action can be called from JavaScript and is generally more flexible, as the action itself can be edited and have functionality added inside CRM.

Having recently created a custom app that integrates with Dynamics CRM, I came across a few issues that took me a while to resolve. This post I’m sharing some of the workarounds I have for those issues.

Async, Async, Async…

When working with the mobile SDK, one of the things you’ll find is that almost everything happens asynchronously. This means all SDK calls take time to come back, and leave the app open to interaction from the user within this period of time that may lead to unintended behaviour – opening multiple Navigation pages, instantiating multiple instances of an object, creating duplicates of an object in CRM, or just throwing errors (null or otherwise), left right and centre.

Some Things You Can Do to Avoid These Issues Are:

• Make clear that there is background interaction happening.
  Whether you’re logging into the service, loading data, or simply populating the information on a page, it can be helpful to provide the user with a visual reminder that work is being done. I’ve found that Activity Indicators and Progress Bars, either used together or separately, can provide the user with enough of a visual indication to dissuade from, as so many users do, just clicking again because it’s ‘not working fast enough’. Running these for the correct period of time can be really easy, particularly for the Activity Indicator. A simple example of this is shown below:
  
  
• Disable any buttons that may cause unintended behaviour.
  When  working with CRM, as most of the calls to the SDK are asynchronous, I tend to put the bulk of my code into asynchronous methods, so I can use .NET’s ‘await’ keyword to obtain the data from the task before proceeding with operations. However, I often have a second synchronous method which fires off the same click event that disables the button. This ensures that there is no time between the button being clicked and disabled for the user to cause unintended behaviour.

Plugins and Triggered Events

When integrating your app with CRM, it’s important to note that the plugins on your target system will still run on the messages created by the calls from your mobile application. This means that performing any action that would cause the web interface to throw an error in the app will have the same result. This is often in the form of an OrganizationServiceFault. It’s important to catch these and deal with them appropriately, be it in the form of informing the user and cancelling the operation, or throwing an in-app error. Not handling these exceptions properly can cause the app to crash.

This is because the plugins act against the SDK messages, and your app uses the same SDK messages as the web interface. This means that you should expect to see the same behaviour from triggered events as well.

Data is Expensive

Data doesn’t always seem too big, but when dealing with several tens of thousands to hundreds of thousands of records, data can come at a big cost, particularly if you want to cache the data for offline use. Consider caching only required data, and for the rest simply downloading and using as needed. If your app involves retrieving all entities of a specific type, consider setting a record limit for a single view, with option to load more if required. This can greatly reduce the amount of data that is required to be stored on the device. However, if the target application has a small data set, this may not be a concern for you.

In this blog I will cover how to retrieve Entity Metadata via the CRM SDK. There are a variety of reasons that you may want to do this in Microsoft Dynamics 365. Recently, I’ve needed to retrieve the display name for an entity while working with a generalised control. The request itself is an OrganizationRequest, so it is executed as normal by using the execute method on the OrganizationService.

The procedure for retrieving entity metadata is relatively straightforward. Let’s first take a look at the general structure of the request, with the required fields used.

 
In order to retrieve the entity metadata, you first need to perform a RetrieveEntityRequest, for which the response is basically just a container for the Entity Metadata.

The required parameters for the request are:

• EntityFilters
  • A filter to control how much data about the entity is returned.
• RetrieveAsIfPublished
  • Set true to include unpublished changes to Entity, as it would look if you called publish.
  • Setting to false includes only published changes to the Entity.

Either LogicalName or MetadataId is required to inform the request which Entity it is you wish to be returned.

From the response, the EntityMetadata can be accessed. What information is contained here is determined by the EntityFilters defined in the request. In our case, this is the Entity’s attributes.

Using the Display Name Attribute of the Metadata

Using the display name is a little roundabout. The code below shows how to use the retrieved metadata to access and use the display name of the entity.

It’s important to note that before you use the Display Name, you need to get the UserLocalizedLabel, and then the Label attribute of that, as the Display Name initially retrieved cannot be implicitly converted to a string, and the ToString() method for which will instead return the type Label object.

When setting a lookup value using JavaScript in Microsoft Dynamics 365, the value you use has to be an array and the values in that array must be of type object. Within the object the required components are the id, logical name and the entity type.

Retrieving a lookup field through JavaScript can be a little more difficult than expected, it is important to note that using business rules you can access the values within a lookup and set other fields with this value. Regardless, there are some cases where you might want to use JavaScript to get a lookup field value.

This is a simple example:

 
The lookup value retrieved is an object and to get each component is shown in the image above. This is the main difference between a regular field e.g. text field and a lookup field, a text field will simply return the text value where the lookup field returns an object. Some small but important components are required when getting the field value. These are that the field is on the form and that the field doesn’t return null, so it’d be wise having a null check.

Setting a lookup value:

 
Alternative way of setting a lookup value with same result:

Registering your app with Azure Active Directory can be incredibly useful for authenticating with services such as Microsoft Dynamics 365. A registered app can request an authentication token with which they can access the Dynamics CRM web API – given they have the correct permissions.

The process for registering your custom application against Azure Active Directory is very straightforward.
1.    Login to your organization at portal.azure.com.
2.    Navigate to Azure Active Directory.

3.    Make sure the domain that you want to register the app against is selected.
4.    Navigate to App registrations.

5.    Select Add – We’ll come back to this page later also.

6.    Fill out the create form with your app’s details.
a.    The redirect URI must be app unique on your selected domain.

7.    Clicking create will redirect you to the App summary.

8.    Take note of the Application ID. You will use this in your application as the client id when you authenticate with an Active Directory Authentication Library.
9.    There’s one piece of information left to gather, and that’s the Authentication URL/Endpoint. Back in the app dashboard (step 5) there is an Endpoint button at the top of the screen – click that and you will be directed to the available endpoints for your application to use. The endpoint you want to copy is the OAuth 2.0 Authorization Endpoint. Use this and the Application Id to update your code.
10.    That’s it! Your app is now registered with Azure Active Directory. If you want to use the app to integrate with CRM however, there is one more step. In the API Access section in the settings panel, navigate to Required permissions.

From there, add a permission for Microsoft Dynamics CRM Online. Once this is done, you can use your app to interact with the Dynamics CRM Web API.

A Bit Extra

For hep building an authentication class, and a simple wrapper to interact with the Microsoft Dynamics CRM and Dynamics 365 web API, a tutorial can be found here:

https://blogs.msdn.microsoft.com/crminthefield/2015/07/22/dynamics-crm-developers-build-your-own-mobile-apps-for-windows-ios-and-android-part-5/

In Microsoft Dynamics 365 when a stage changes in a Business Process, you may want to run a workflow to automate the fetching of information, an invoicing process, or any other number of things. This is incredibly easy to do with Microsoft Dynamics 365.

In the new business process flow designer, simply select Add > Add Workflow, then select the stage within which you want to run the workflow.

This will add the workflow item to the stage, from which you are able to select the trigger that you would like the workflow to run on (Stage Entry or Exit), and then also the workflow itself that you want to run. Note that there is a caveat for the workflow selected, that it must be an active, on demand workflow for the same entity as the selected stage. The selected workflow will now run on the selected trigger.

Once you’ve created your custom entities in Microsoft Dynamics 365, you’ll probably want to give them custom icons to make them more easily recognisable, and to give the entities a more finished feel.

Thankfully, this is very easy to do in Microsoft Dynamics 365. Simply acquire the image that you want to use as the icon for the entity, then create two copies of the icon, of sizes:

• 32 x 32 px
• 16 x 16 px

The reason for this is that Microsoft Dynamics 365 uses the two differently sized icons in different places. For example, the 32 x 32 px image is used in the site map, while the 16 x 16 px image is used in lookup fields.

In order to use an image as an icon, the image must first be uploaded as a web resource formatted as a .png, .gif, or .jpg. The image also must be smaller than 10 kB.

When you’ve uploaded your desired image, navigate to you custom entity in the solution explorer in Dynamics 365, and select the update icons button at the top of the window. This will open a wizard which will allow you to select your image.

Some Considerations

When selecting an image, you may want to consider using a vector image, as these scale very nicely, and remain sharp no matter the resolution. Also, in interests of keeping things consistent, consider either styling the icons to remain consistent with the out-of-the-box Dynamics 365 icons (white on a transparent background, material design), or making all of the icons for your custom entities consistent in some way.