June 2017 Blog Review

There were lots of great posts shared in June but first a quick reminder to check out your local CRMUG events! CRMUGDC (Washington, DC Chapter) will be hosting a combined event with the Reston, VA chapter. This Summit Preview will be a full day event with 6 speakers! We will discuss a variety of topics from How to Use CRM to Drive Success to Extending Workflows; from Administrator Tips to Virtual Entities and Odata consumption. This is going to be a great event for all experience levels and job roles. To learn more and register check out the chapter page at CRMUG.com/Washington!

Ledgeview Partners shared Using Advanced Find in Microsoft Dynamics 365/CRM. This article walks through the information needed to get started on your first Advanced Find. This is a powerful skill that helps you understand more about CRM and how your data is related.

System Administrators often need to add new fields to their CRM implementation. There are several articles to check out on this topic:

• 5 Tips for Creating New Fields: My post on CRMUG
• Exploring Field Types - Rollup Fields: PowerObjects
• Exploring Field Types - Calculated Fields: PowerObjects

PowerObjects also shared Custom Action Quick Tips. Check this out to learn how to create a simple Action that can be used to do more complex logic without code. Refresher: Custom Workflow steps are code pieces that can be called by a workflow to do more complex steps, Actions are additional steps built inside CRM that can be called from code or workflows. Actions allow for the input of parameters as well.

Sonoma Partners worked to help with a very confusing topic in Best Practices for Microsoft Security Settings: Append vs. Append To. This discusses the differences between and meanings of the Append privileges as well as some tips to keep in mind.

This month details were also released on the July 2017 release for Dynamics 365. To learn more check out Jukka Niiranen's All You Need to Know About Dynamics 365 v9.0 (For Now) and Chris Cognetta's Dynamics 365 Spring Release: 5 Takeaways from a Business Solutions MVP.

As always, keep an eye on the CRM Tip of the Day to see if there is anything relating to your organization. This month I was particularly interested in:

• Pets are Dangerous
• Start Planning around Deprecated Features
• Developers, Start planning for New Features

That's all for today. Back to summer CRM enhancements!

Field Level Security vs. Not Searchable

I have found that there can be a bit of confusion about what making a field Searchable=no means. Someone may say, “Set this field to not searchable and remove it from the form so no one can access it.” Sadly, this is not exactly the case.

Review the chart below for a bit more information:

	Remove from Form / non - Searchable	Field Level Security	FLS & Non-Searchable	Delete Field
Pros	·         All data is saved ·         Existing searches with field as criteria cannot be run	·         Access could be granted to specific groups if desired ·         All data is saved	·         Existing finds using field as criteria cannot be run ·         Column can be added but will not display data	·         Cannot be included in Views ·         Not Searchable
Cons	·         Data is still viewable in Finds ·         Non-searchable for everyone	·         Field can still be added to views even though data is not returned ·         Views with field as criteria can be run but return no data	·         Some users can be given access to view data in field but all users will be unable to search for it	·         All data is lost ·         Manual change in all environments
Form	·         Remove	·         Remove	·         Remove	·         Needs to be removed from form prior to delete
Existing Views	·         Criteria: on Find page "There was an error in showing this condition". When running "There are some clauses that have errors in them please remove and try again" ·         Column: Data is still Visible ·         Criteria & Column: Same as Criteria above	·         Criteria: no error on criteria, find returned is blank (I cannot see the data) ·         Column: Column is visible, no data is displayed ·         Criteria & Column: Same as Criteria above	·         Criteria: on Find page "There was an error in showing this condition". When running "There are some clauses that have errors in them please remove and try again" ·         Column: Column is visible, no data is displayed ·         Criteria & Column: Same as Criteria above	·         Error: "To Use this saved view, you must remove criteria and columns that refer to deleted or non-searchable items"
Future Views	·         Criteria: Cannot be added ·         Column: Can be added, data is still visible	·         Criteria: Can add but no data will be returned ·         Column: Can be added, no data is returned	·         Criteria: Cannot be added ·         Column: Can be added, no data is visible	·         Cannot be included

See making a field Searchable = no only does exactly what it says. It stops users from searching for the field. It does not prevent people from viewing and using the data already in the field. If the field is removed from the form, it will not be easily accessible but can be viewed in Advanced Find. Don’t forget users could already have Advanced Finds with the field in it, they would not notice a change.  But if it was criteria in an existing view, they would need to change it.

Now Field Level Security effectively hides the data everywhere. If a user does not have access they will not see any of the data contained in it. However, the field could be included in Find Criteria and Columns but it would act as if the field was always blank.

One other note, if you enable field security on a field it will automatically be hidden from everyone except users with the System Administrator role. Then you can add it to other FLS Security Profiles if you need to. (Side note, FLS is not role based. System Administrator is a special case. Users and Teams are added directly to FLS profiles.)

I hope this clears up some confusion!