Showing posts with label CRM 2016. Show all posts
Showing posts with label CRM 2016. Show all posts

Monday, 21 May 2018

Unboxing my Microsoft MVP award

22:41 Posted by Benitez Here , , , ,
Earlier this month I was awarded by Microsoft as a MVP in Business Solutions. Around the world, there's 200+ Business Solutions MVPs and in Australia there is now 13 MVPs. Being the first female in the Australia/NZ region is an incredible feeling and it was truly a special moment for me when I found out I had been awarded.

*Edit: actually I'm the second, found out there was another female awarded a few years ago. I am currently the only awarded female*

I thought I'd share the moment I opened my Microsoft MVP gift package through a vlog. I hope this inspires others, especially those who have started their journey with Dynamics, PowerBI, PowerApps (list goes on) to share what they know by contributing to the community whether it be a podcast, blog or vlog.

Notable mentions

Andre Margono - one of the nicest and kindest people I've worked with to date. He nominated me last year after our first Dynamics 365 Saturday here in Australia.

Julie Yack, Leon Tribe and Neil Benson - for supporting my nomination.

Sophie Khun-Hammond - I learnt CRM4 from her back in 2009 and she was more than happy to show me the ropes. She is the foundation of my learning and really appreciated her guidance during that period of my career.

Lastly, Ben Hosking - in 2014 I reached out to Ben and said I always wanted to blog and do video blogs but had been afraid to do so. Through his encouragement from the other side of the world, I plucked up the courage to start blogging and vlogging. A little bit of encouragement goes a long way.

Ben, I still have that message if you're reading this. Thank you.


Thanks everyone. More vlogs coming.



 

Tuesday, 9 January 2018

Vlog Blooper Reel

22:21 Posted by Benitez Here , , , No comments
Happy New Year to 2018!

Here's a blooper reel I put together.


Vlogging can be hard at times as you're simultaneously thinking about your next steps/clicks that you're going to show and discussing it while being recorded. There's times where I will accidentally slip up on camera which you don't normally see! But I still love it #vloglife

I'll be posting a new Dynamics Portals vlog next week so make sure you've subscribed to my YouTube channel to get instant notification when I've published a new vlog.

For some other humour, check out Ben Hosk's funny video.

Sunday, 10 September 2017

Using App Designer to change the end user experience with Dynamics 365

22:38 Posted by Benitez Here , , , No comments
In my last blog post I shared customization and configuration tips for Dynamics 365 where the last tip I shared was to use the App Designer to change the end user experience. The App Designer was introduced towards the end of last year (I think) and it's a step up from what we previously knew about configuring Site Maps. It's one of those features that has made me appreciate how far Dynamics CRM has come as it's a neat way of reducing the noise and distraction for end users without having to resort to code.

One of the recurring themes I had in my last post was to minimize "clutter" for end users, hide anything that is not of use to them when they're interacting with Dynamics 365. When they log in, they should only see what they need to see when navigating within the menu and only have access to entity forms, views and charts that are relevant to them. This can be achieved using the App Designer.

Tell me more...

Previously if we wanted to change the default menu that comes with Dynamics 365, we would turn to the Sitemap Editor in XrmToolBox. The Sitemap Editor was our best friend for those who weren't familiar with editing the raw FetchXML. However if we go back to the principles of Dynamics CRM, the sitemap is a "global" function - it applies to all end users. A change you make such as removing the Service tile from the menu/site map means any end user when they log in will only see Sales, Marketing, Settings and Help. You're not able to show and hide the Service tile and it's respective records based on an end user's security role. You could add a privilege node for the entity that needs to be displayed or hidden but 
  1. You'd have to be confident in doing this with the Sitemap Editor in XrmToolbox.
  2. It can be confusing if you're not familiar with the security role privileges and is hard to maintain in the long term as the configuration resides within XrmToolbox. It's not something you can see within Dynamics 365 administration or customization settings.
  3. This is a risky configuration option and I have not worked with a customer who has chosen to go down this path as once I've explained it to them, they are confused and prefer to display the entity in the menu but restrict the Read access through the security role privileges. Plus you can also hide an entity from the menu within the customization settings of the entity.
This is where the App Designer comes in handy as
  1. It's configurable within Dynamics 365 which means the customer can update it themselves in the future post go-live.
  2. It's simple for end users to configure. They simply click or drag and drop to configure the Site Map.
  3. You can create many Site Maps through the concept of an "App" and assign security roles to the App. No need to create privilege nodes and be in fear of whether you correctly configured the privilege node in alignment to the security roles. You're no longer tied to a single Site Map and can restrict the Apps to certain security roles.
BUT... you can do more than Site Map configuration with the App Designer. This is what I cover in my vlog. Check it out by watching my vlog below.

How to create a new Dynamics 365 App

What you need prior to creating a new App
  1. An unmanaged solution to create the App in.
  2. System Administrator or System Customizer security role.
  3. A plan of what entities you would like displayed in the menu, as well as the what other entity components you would like the end user to have access to.
  4. A plan of the security roles that are permitted to use the App.

Creating the App

Open your unmanaged solution and on the left hand side you'll see a new component called Apps.
Click on New.

A new window will appear where you can
  1. Enter a Name for the App. This is what the end users will see.
  2. Unique Name is the schema name for the App.
  3. Select an icon. By default, there will be a default icon that is used. However if you have uploaded a web resource with a .png that is to be used as the icon, simply untick the box and a dropdown field will appear where you can select the web resource.
  4. Enter in a suffix for the url of the App.


Once you're happy with the details, click Done. You'll have a new window appear where you can configure a Site Map for the App.


Click on the arrow icon to configure the Site Map. You'll now be able to add 
  1. Area which is a menu tile (eg. Sales).
  2. Group which is the heading or category of what will sit underneath it.
  3. Subarea with is either a dashboard, entity, web resource or URL.


To add the components, you can either
  1. Click on Add and select what component you want to add.
  2. Drag and drop the component from the right.


For each component you add in, enter in the details on the right hand side. 

When adding a new Area, you enter in a Title and select an icon. Icons are web resources so if you have a custom icon, make sure it's a web resource within the unmanaged solution the App resides in.


For a Group, all you need is a Title.


For a Sub Area, this is where you can pick what type you would like to be displayed. A majority of the time it will be an entity but there are other options that can be selected. If the entity has an icon associated to it, it will automatically load by default.



Once you're done with configuring the Site Map, it should look something like this:


Save and Publish your Site Map. When it has completed, you'll see the buttons disabled as per the above.

Click Save and Close. You'll be directed back to the App Designer where you can do extra configuration on top of the Site Map.

Do tell me more...

Remember earlier when I mentioned you can do more than configure the Site Map the App Designer? You can also hide other elements to minimize clutter for end users #winning

Displaying dashboards

If you click on dashboards, it will display the list of dashboards available within the Dynamics 365 instance on the right hand side. You can select what dashboards you want to be visible for the App. Continuing with the last screen shot, I've created an app for the Service Desk team. I only want them to see dashboards related to Cases. I simply tick the check boxes for the dashboards I want the end users to see.


Displaying Business Process Flows

Same applies to Business Process Flows, it will display the list of Business Process Flows available within the Dynamics 365 instance on the right hand side. You can select what Business Process Flows you want to be visible for the App. 

Displaying entity level components

This one is my personal favourite :) 

You can hide and show Forms, Views and Charts for each entity! Why am I excited about this? Because I get asked to hide Views all the times by customers. Now you can do it with the App Designer.


You can also hide the Forms as well within the App Designer. You can also still use the existing configuration feature of hiding it based on security roles (you do this with the form customization). 


Side note: hiding Forms is something I come across more frequently in my projects these days as I work with customers who are also implementing Dynamics Portals. In Dynamics Portal, you do create new entity forms for the purpose of displaying them on the portal. These forms often don't need to be seen by end users.

Same with Charts, you can select which charts you want to be displayed to end users.


When you're done selecting what you want to be displayed, save and Publish the App. Exit out of the App and you're good to go :)

Enabling security roles to access Apps

The next thing you will need to do is enable security roles for any Apps that have been configured.

Normally you browse to Settings and you see Apps under Applications. However I have found that in the latest version of Dynamics 365 it's not appearing where it should be.


Fear not, Benitez is here! You can view your list of Apps by browsing to https://<instancename>.crm6.dynamics.com/apps. Simply end apps as a suffix your Dynamics 365 instance URL.

You'll see a list of Apps and to enable security roles for an App that has been created, click on the ellipsis and select manage roles.


You can then select the security roles that you would like to have access to the App. Select the security roles and then hit Save.


Time to test. Log in as an end user with the security role and they will now have access to the App.


Check out your components that you configured to display certain records such as Views. In my example, I restricted the Case Views for the Service Desk app.


Bonus Tip

Before you export your unmanaged solution, you need to add the sitemap component to your solution. It's not obvious the first time you create an App and you only find out when you do a deployment for the unmanaged solution. You'll get a prompt that it's missing from your solution.

Simply go to Components in the unmanaged solution and select Site Map.


Select the Site Map for the App and it will be added to the unmanaged solution.


My learnings

Copying and restoring Production

I found that if you copy and restore the Production instance into a Sandbox instance, the App URL's will point to Production. I'm not sure if the Dynamics 365 Product team is aware of this behaviour but I came across this when working with a customer earlier this year.

Apps simply hide components on the surface

If a entity is not displayed on the Site Map of an App, the end user can still get to the entity through Advanced Find. So don't think this will prevent the end user in accessing entities they 100% should not be allowed to access. You still need to work with security roles in removing access to entities.

More analysis and customization time required

Don't get me wrong, I love the App Designer. However there is something all consultants and customers need to be aware of. Due to the App Designer allowing more than one App to be created, more time and effort is required here. The customer needs to invest in planning what Apps are to be created and what end users will have access to these Apps. 

If there is a desire by the customer to have "regional" based Apps, this requires careful considerations. A customer I have worked with here in Australia wanted Apps based on the State and Territories such as an App for Victoria based end users. I advised the customer that they need to put more thought into this as this will require a number of views across Dynamics 365 entities to be created that will fit the requirement of State based Apps. For example, when viewing Contacts what constitutes a Contact as being in the Victoria region? Is it by the Territory record associated to the CRM User record that is the Owner of the Contact? Or is it the Address 1: State/Province field where it equals "VIC" or "VICTORIA?"

Regional Apps can be created but need to think about how the views will be impacted. Plus the maintenance of the views can be cumbersome long term as you'll have to update all the regional views that have been created.

Summary

The App Designer allows the configuration of the Site Map and the visibility of components for the end users when navigating in Dynamics 365. The best bit is that no code is required. It is also available within the Dynamics 365 interface which is good for the customer as they can go to one place to edit any Apps.

By displaying Areas and Sub Areas tailored to specific security roles changes the end user experience. You can make end users focus on what they need to see to do their job or daily tasks within Dynamics 365 by removing any unnecessary noise. Keeping it clutter free makes their experience with Dynamics 365 much smoother.

Till next time, toodles.

Sunday, 27 August 2017

Dynamics 365 Customization and Configuration Tips

20:35 Posted by Benitez Here , , , No comments
I recently presented at CRM Saturday Melbourne and CRM Saturday Sydney. CRM Saturday is a free CRM Technical and Strategy event organised by the Microsoft Dynamics Community MVP's for customers, CRM Professionals, Technical Consultants and Developers. It gives you the opportunity to learn, share knowledge and meet peers in our line of work. It's a fantastic event and definitely attend one if there is a CRM Saturday where you are. The last one for the year 2017 is in Milan.

Thanks Greg for the photo 

I decided to present on tips that I've come across over the years with Dynamics CRM. I started my journey with Dynamics back in 2009 with CRM 4. It's changed over the years from CRM 4 to CRM 2011, to CRM 2013, to CRM 2015, to CRM 2016 and now Dynamics 365. New features have popped up along the way which all consultants needed to learn in order to assess whether they would be of value to the client/customer.

Even though these new features are amazing compared to the previous version of CRM, the fundamental principals of Dynamics CRM still exist. Creating a field, adding a new section onto a form, creating a workflow... these are still the basics that exist today. As years have passed, I've come across these tips (or even best practice) to apply for customization and configuration of Dynamics 365. Some you may be familiar with already, others not so much.

What's the difference between the two terms?

The definition of customization vs configuration is always a debatable topic in the community. For me, I follow the explanation outlined in this article.

Customization

  • Anything that can be done within CRM without resorting to the SDK or external code. 
  • Adding new fields to an existing entity, creating new entities, option sets, reports etc.
Examples include Fields, Entities, Relationships, Forms, Views etc.

Configuration

  • Any changes made to existing options available within the default installation of CRM.
  • Configuration applies to objects like: Business Units, Security Roles, Users, Teams, Auditing etc.
Examples might include changing the default currency from USD to AUD or setting up Mailbox Profiles.

My tips

1. Reuse system fields where relevant

For out-of-the-box entities such as Contact, there is a list of fields that are created as part of the default installation of Dynamics 365. This is what we call a "system" field. Often there are times where a data type can be captured in a system field and the only change that needs to happen is to relabel the field display name. It's good to relabel a field if it can be used rather than creating a new field. Saves one extra field from being created.

The most common one I tend to relabel is the Birthday field.


A lot of customers I have worked with usually want this to be relabeled to Date of Birth. To relabel a field, go to the entity in your solution and open the field attribute record. Change the Display Name to the desired label.

Bonus tip

It's important you do this within the Field Attribute record in the target CRM Solution and not within the Form Display Field Label customization. If you make the change within the Form, it will only change the label at the Form level. 

Why should you care? End users expect to see the field label that's on the form in Advanced Find or Views as they're not familiar with the schematics of Dynamics 365. I've come across this many times in my career where the field label was changed within the Form and support tickets are raised because they can't find the field they see on the Form in Advanced Find or Views. 

Make sure you always update the field label within the Field Attribute record.

2. Update system field to not be searchable

I'm a big fan of less is more, be clutter free in Dynamics 365. Not all system fields will be used by end users. Yes, you can remove system fields from the Contact form such as the Address 1: Shipping Method. 



However it will still appear in Advanced Find when end users are wanting to view a list of records with specific criteria.

To minimize the list of fields that is displayed, simply hide any system fields that will not be in use by updating the searchable option from Yes to No in the field attribute record.


This ensures that fields used by end users are only displayed and that they don't have to trawl through a long list.

Before

After

A reminder that this will only prevent the field being displayed in Advanced Find. The field will still appear when adding columns to within Advanced Find and in Entity System Views within your solution.

Bonus tip

If you want to perform a bulk update of fields to not be searchable, you can use Attribute Bulk Updater in XrmToolBox. This will save you time as you can do it in one go rather than painfully open the Field Attribute record one by one. Raising my glass to the fellow CRM'er who designed this nifty tool.

3. Append “id” to custom lookup fields

When creating custom lookup field, append "id" to the end of the schema name. This is so that end users or even colleagues in Managed Services in consulting companies know that the field is a Lookup field which is an association to another entity. For developers, it's so handy for them as they immediately know that this field is a foreign key in the source entity. Ben Hosk outlined this as a useful tip too.

4. Removal of double prefix in relationships

This one is more of a "I like to keep it clean" tip. When creating a custom Lookup field, the schema relationship name will automatically render a double prefix as you're creating it within a Solution that has a prefix defined. I tend to remove the additional prefix cause I find it more tidier #neatfreak

5. Mapping from source record to target record to reduce data entry

If you don't already know about this customization feature, then you're about to learn :) One of the cool things you can do is grab data from a field in a source record to a target record. The condition here is that the field attribute type must be the same. In other words, if a field in the source record is a Single Line of Text field then the field in the target record must be Single Line of Text too.


This is handy when you want fields to be automatically populated when creating a new record from an associated record. For example, creating a new Membership record from a Contact record where data from the Contact record is brought across.

6. Apply Global Option Set where relevant

The difference between a Global Option Set and an Option Set is that the former can be reused across Dynamics CRM whereas an Option Set is restricted to the entity that it is created in. For example if you create an Option Set within the Contact entity, you can only use it within the Contact entity.

Global Option Sets are handy for customers where the same values in a list will be used across Dynamics 365. One that I always create is a Yes/No Global Option Set. This is useful for customers where a Two Option/Boolean field is not appropriate as they require the end user to select Yes or No where the default when creating a new record for the first time is required to be blank.

The screenshot example below is for Membership Organisations where typically Member Type is used across Dynamics 365.

7. Tidy fields and navigation pane on out-of-the-box forms

With out-of-the-box entities, there is default forms with system fields already inserted into the form. Remove the system fields from the out-of-the-box forms such as the Contact main form that will not be in use by end users.  


Same goes to the navigation pane on the out-of-the-box forms by removing any related records that will not be in use by end users.


This is so that end users only focus on what they're meant to see and have access to. Keep the end user experience clean, remove the unnecessary noise.

Bonus Tip

If you want to save time in removing fields from entity forms, use the Bulk Form Attribute Manager in XRMToolbox. This will display all fields that are on forms and you can select which ones you want to remove.


8. Entity Form Tab naming convention

Tabs allow sections and fields to be grouped within an entity form. When you create a custom tab on an entity form by default the tab will be given a string as the Name value.


If you look at out-of-the-box entity forms in Microsoft Dynamics 365 (in my case, Contact) the naming convention is: <Tab Name>_TAB.


Follow this naming convention for consistency throughout your solution.

9. Section naming convention

After discovering the above about four years go, I decided to investigate the naming conventions for Sections. Sections allow fields and sub-girds to be inserted within an entity form.

I found that the Section naming conventions are not consistent out-of-the-box. I think this is due to how CRM started out with Version 4 and the underlying schema has remained the same for sections.
To keep it consistent with Tab Naming Conventions, use the format of: <Section Name>_SECTION.

10. Update out-of-the-box system views Consistency of views using View Layout

The current theme you'll find in this post is about keeping the end user experience clean, consistent and clutter free. This tip is about ensuring Views are consistent, for example the columns in the Active Contact view can also be the same for the Contacts Inactive View.

Before

After

I've done a lot of customization over the years and I found this to be a common recurrence with customers where they expect the same columns in a majority of entity views.

Bonus Tip

View Layout Replicator in XrmToolbox can be used for achieving consistency of views. You basically select a source view that contains the columns you want to be applied to other views. Once you select the source view, you can select the target view and simply publish the changes.

11. Sequential Business Rules

I presented this tip at the Melbourne Dynamics 365 User Group back in October 2015.



This is something painful I experienced two years ago when working on a government project. There was quite a few Business Rules that we were implemented on a form. I had odd behaviour happening that I didn't want, and the Business Rules that I wanted to work when required (such as when field xy is updated, do abc...) never did. It drove me crazy and then after doing some Googling, I discovered the Business Rules will execute based on the order it was activated #goodtoknow #whydidntanyonetellme #wastedhours

Thankfully, I get to share this one with you. To prevent conflicting Business Rules, use a numbering system in the Name and activate them in sequential order.

My bonus tip for this is to append 0 for single digit numbers to ensure business rules displaying sequentially.

Before - no 0 appended before the single digit number

After – 0 appended prior to the single digit number

I actually had someone from the audience come up to me afterwards saying they went through this exact same problem and thanked me for my tip which was nice. It's so simple yet effective.

This is also really great long term for CRM super users or Managed Services consultants. 
  1. If you have enhancements in the future where additional Business Rules is required, deactivate all Business Rules and rename them in order. Then activate them in the required order.
  2. When trouble shooting as part of a support ticket/case/service request and the Business Rules is required to be deactivated for issue resolution, you'll know which order to activate it once fixed.

12. Improve Quick Find Search duration

By default when browsing through entity views or search results in Microsoft Dynamics 365, the number of records is limited to 50 records per page of the view.

When using the Quick Find Search, sometimes you use the wildcard function (*). For example, search for “*com” against the Active Accounts View. This will retrieve any account record that contains “com” in the fields that have been enabled for Quick Find Search.

You can increase the performance of the search by increasing the Records Per Page limit from 50 to 250. 

To read more about this, checkout this post.

13. Using App Designer for a better end user experience

A new feature that was introduced in Dynamics 365 is the App Designer which allows you to create a new app which can be selected from Dynamics 365 and restricted to specific security roles.


I'll demonstrate this further in my next post so keep your eyes peeled. Subscribe to my blog if you haven't already done so.

Summary

All of the above is tips I've accumulated through out my journey with Dynamics 365. The fundamental principals still exist inspite of new features being introduced in each release. I hope you've learnt something from me today.

Below is a copy of my slides I used for CRM Saturday Sydney.
Note: the slides will automatically go to the next slide after 15 seconds.



Enjoy. Toodles.