Your cart is currently empty!
Author: Heidi Neuhauser
-
Getting started with Field Level Security in Dynamics 365
As a CRM System Administrator, you have many incredible, out-of-the-box configuration super powers in your toolkit. Today, I want to focus on one of these super powers: field level security.
What is field level security and when would I use it?Field level security gives you the ability to limit user groups who can read, create or update to a field. Here’s how that translates in the business world. In the following scenarios, adding Field Level Security can meet these business and user requirements:
- Your organization has an approval process. Sales reps enter data into a Quote, then a special team of Approvers has the ability to add data in fields. Sales reps should only be able to view this data – never edit it.
- Your organization stores confidential customer information in CRM. Only certain user types should be able to read and edit that data. All other users should never be able to see it.
In all of these cases, using simple out-of-the-box field level security can answer these requirements!
How do I get set up field level security in my Dynamics 365 system?There are three steps to set up field level security:
Enable field securityConfigure a field security profile and add usersSet permissions for a fieldEnabling Field SecurityThe first thing we need to do is enable field security for a specific field. Open the field, and simply click Enable on Field Security (highlighted below).
Enabling Field Security on an individual field in Dynamics 365. Repeat the above process for any fields.
Configure a Field Security Profile & Add UsersAfter you have enabled field security on all fields, the next step is to configure a Field Security Profile. We will walk through the process of creating a Field Security Profile using the Maker Experience AND the Classic Experience.
Using make.powerapps.com:
- At the top, of your Solution, click +New
- Select Other, then select Field Security Profile
Configuring a new Field Security Profile in the Maker Experience. Using Classic Experience
- In your solution file, click +New
- Select Field Security Profile
Configuring a new Field Security Profile in the Classic Experience. Next Steps
Regardless of which experience you used to create your Field Security Profile, the remainder of the steps are identical:
- Name your Field Security Profile in the new window that opens, then click Save at the top.
Add a Name for your Field Security Profile, then click Save. 2. On the left-hand side of the Field Security Profile, you can now add Teams or Users. Add the appropriate users/teams to your Field Security Profile.
Use the Add button highlighted here to select Users or Teams in your organization. Set Permissions for Each FieldNow that you have set enabled Field Security on selected fields, built a Field Security Profile and added users, it’s time to set permissions for each field!
In your Field Security Profile, click Field Permissions on the left-hand side (highlighted below). A list of all fields with Field Security enabled will appear.
Field Permissions within a Field Security Profile. There are three permission levels for each field:
- Read: Users belonging to this Field Security Profile will be able to read data in this field.
- Update: Users belonging to this Field Security Profile can edit and update data in this field.
- Create: Users belonging to this Field Security Profile can create data in this field.
To set permissions, open each field individually and set the appropriate permissions:
When you have completed this process for all fields, click Save and Close at the top.
Closing ThoughtsField Security Profiles are powerful tools to lock down data when needed. If you need help getting started or setting up field security in your organization’s Dynamics 365 organization, feel free to reach out to reenhanced! Fill out our Contact Form with details about what you’re working on, or email me directly at heidi@reenhanced.com. Happy configuration!
- Your organization has an approval process. Sales reps enter data into a Quote, then a special team of Approvers has the ability to add data in fields. Sales reps should only be able to view this data – never edit it.
-
Getting Started with Field Level Mapping in Dynamics 365
As a CRM System Administrator, you have many incredible, out-of-the-box configuration super powers in your toolkit. Today, I want to focus on one of these super powers: field level mapping.
What does field level mapping do in CRM?Great question! Field level mapping (or mapping entity fields) allows you to map attributes between entities that have an entity relationship. It’s a tool that allows you to eliminate end users to enter data in multiple places.
Let’s provide an example to illustrate how this could work. Today, your organization is capturing Lead Type on the lead form and also asking for users to select Opportunity Type on the opportunity form. Even though it’s using the same values (Commercial/Industrial or Residential), it is two separate fields that users have to enter.
To simplify the user experience, you can edit the relationship between Lead and Opportunity, apply field level mapping and have the Lead Type value automatically move over to Opportunity Type when the lead is qualified.
Some fields move over automatically using field level mapping on the relationship. One good example is when you add a Contact to an Account. The Contact automatically inherits the address and phone number from the Account. Is it magic? No, it’s field level mapping!
How can I add my own custom field mapping?Simple! In a solution file in your Sandbox environment, add the appropriate relationship (1:N or N:1). If a relationship does not yet exist between the two entities, you will have to build one. In the below screen shot, we are editing the Lead to Opportunity relationship. On the left-hand side, click the Mappings icon:
Within the entity relationship (1:N or N:1), click the circled icon for Mappings. This opens up a new window where you can create field mapping from Lead to Opportunity (or which ever entities you have selected). The left-hand column shows all fields eligible to be mapped from the Source Entity (in our example, the Lead). The right-hand column shows all fields for the Target Entity (in our example, the Opportunity). Select the appropriate field(s) and click OK.
Make the magic happen! Select field mapping here, then click OK. Once you’ve published changes to the relationship, have your user group log in and test to ensure this is all working as you expected it to. With their approval, go ahead and move these changes into Production and celebrate the magic you created!
The Field Level Mapping Playbook & RulesWith all features like this, I think it is extremely important to share the rules and lessons learned. Here are a few things you should know about field level mapping before you get started:
Fields must be the same type and formatLength of the Target field must be equal or greater than the length of the Source fieldYou can only apply field level mapping to a field one timeThis will not work with hidden fields: the source field must be visible on the formFor Option Sets to be mapped, they will need to have matching integer values (not just matching text!)
(Global option sets make this simple!)Where can I learn more?If you need any help with field level mapping, feel free to reach out to us or email me directly at heidi@reenhanced.com. We’re happy to help if you have questions or get stuck. You can also check out this user guide from Microsoft documentation. Happy mapping!!
-
Model-driven Apps in PowerApps: Managing Properties
Welcome to the fifth and penultimate article in the model-driven app series! Today we will look at managing properties in a model-driven app. This series includes six articles that will help you to get to know and use model-driven apps and PowerApps:
Managing PropertiesNow that we have reviewed security considerations, understood how to use the App Designer, learned about the controls and power of the Site Map and added components to the app, we can move on to reviewing some of the properties available.
In the App Designer, we have been working in the Components tab. If you click on the Properties tab, shown in the screen shot below, you have access to a number of areas to update and customize.
Click the properties tab in the App Designer. You can edit the following areas:
- Name: The name of the App that displays to users.
- Description: Description of the App that will appear to users.
- Icon: By default, it will use the Default image. Follow the steps below to update icon image.
- Advanced: Modify unique name, unified interface URL, add a welcome page and enable Mobile Offline in this area.
Adding a logo (or other Image) to your App!If you want to use an image apart from the default Microsoft image (below), you can follow these three simple steps:
Default image - Add New Web Resource to your solution
Add a new web resource & select image/logo. - In App Properties, uncheck the box “Use Default Image”
Uncheck this box! - Select the logo/image you added in step 1 and view a preview of the updated App image. When complete, click Save at the bottom of the Properties tab.
Preview your updated App image Building a Model-Driven App in Dynamics 365 Using PowerApps & Out-of-the-box Functionality Series Almost Complete!There is only one article left in our series: focused on the Users. Stay tuned for the exciting conclusion!
-
Model-driven apps in PowerApps: Components
Welcome to the fourth article in the model-driven app series! Today we will look at the Components in a model-driven app. This series includes six articles that will help you to get to know and use model-driven apps and PowerApps:
ComponentsIf you haven’t already familiarized yourself with the Site Map and how it works, take a moment to read the blog here. After you have created your Site Map, the next step is to add and define the various components on the App Designer.
Components are displayed on the right-hand side of the App Designer:
Components are listed in the panel on the right-hand side of the App Designer. The Site Map is your foundation and the components are the building blocks you layer on top to build your App. Components are comprised of:
- Artifacts: Entities, Dashboards and Business Processes Flows
- Entity Assets: Forms, Views, Charts and Dashboards
Components in the App Designer. Artifacts- Entities: In most scenarios, the Artifacts will populated based on what you have selected in the Site Map.
- Dashboards: Select the system dashboards that should be included in the app.
- Business Process Flows: Select any business process flows to add to your app. Any active, published business process flows
Entity AssetsOnce you start adding entity assets to your App, you can really work on streamlining and enhancing your end user experience! Always keep in mind who your audience is for this App. What are the only pieces needed for this group of users to do their job? The minimum amount here is key. Give them only what they need in order to successfully do their job and eliminate all of the other noise. This is my favorite part about model-driven apps and Dynamics 365. This sort of thing used to require custom code – and now I can use simple configuration to accomplish the same thing.
- Forms: Define which forms should display for each entity. At least one form must be selected for each entity.
- Views: Select only the necessary views to be included in this App. At least one view must be selected for each entity.
- Charts: Select any system charts for the entity.
- Dashboards: Select dashboards for the entity.
Now that you have created a Site Map for your app and added all components to is (both artifacts and entity assets), your model-driven app is really starting to look good! The final two parts of this series will cover properties you can set and why this is important to your end users.
-
Model-driven apps in PowerApps: Site Map
Welcome to the third article in the model-driven app series! Today we will look at the Site Map and understand how it works from the back end / system administrator view and how that translates to the front end / end user view. This series includes six articles that will help you to get to know and use model-driven apps and PowerApps:
Security ConsiderationsUsing the App DesignerSite MapComponentsManaging PropertiesBenefits to Your UsersSite MapThis is the single most important component of your model-driven app. It controls which areas of Dynamics 365 are accessible in your App. When building your app, you will have two options when it comes to a site map:
- Use existing (from a solution)
- Create new
Your map consists of three components:
- Area
- Group
- Subarea
Let’s first look at these three components from the back end view for System Administrators and app builders:
The site map from the build perspective Utilizing a simple drag and drop interface (similar to what you see when building Business Rules and Business Process Flows), you can add new Areas, Groups and Subareas to your Sitemap Designer. But what do these mean to the end user? What is the difference between the three components and how do they display?
To best understand the difference between an area, group and subarea on the Sitemap Designer, let’s take a look at the end user / front end view of the sitemap:
The site map from the end user perspective Take a look at the image above to understand how the site map displays to users. The table below will explain how the highlighted colors relate to the Sitemap Designer.
Highlight color Sitemap Designer Detail Blue Area Green Group Yellow Subarea Now that you understand what each component is, build out your app’s sitemap. Once you have completed the build, make sure to Save it by clicking the Save icon in the top right-hand corner of the Sitemap Designer. Next, click Publish.
After your site map has been saved and published, it’s time to move on to the fun stuff – adding components and setting properties. Stay tuned for the next article in our series, where we dive into components (entities, dashboards, business process flows and more)!
Need Help?
Do you need help planning your Site Map? Feel free to reach out to reenhanced! Fill out our Contact Form with details about what you’re working on, or email me directly at heidi@reenhanced.com. Happy building!
-
Model-driven apps in PowerApps: Using the App Designer
Welcome to our second blog in the model-driven app series! Today we will focus on getting to know the App Designer. This series includes six articles that will help you to get to know and use model-driven apps and PowerApps:
Security ConsiderationsUsing the App DesignerSite MapComponentsManaging PropertiesBenefits to Your Users
A blank canvas to build your model-driven app! When you open your model-driven App in the App Designer, it will resemble the image above. You will notice a few main areas here:
- Site Map
- Dashboards
- Components (Artifacts & Entity Assets)
- Properties
Using the App Designer is fairly simple and should be familiar to System Administrators as it uses a similar drag and drop configuration style used in building business rules and business process flows. Microsoft has done an excellent job making configurations like these accessible to the less technical System Administrator (like yours truly!).
Let’s briefly look at each of these – as all of these areas will be covered thoroughly in subsequent articles.
App Designer AreasSite Map Controls which areas of Dynamics 365 can be accessed in this App Dashboards List of any system dashboard included in the App Components A list of entities and entity assets (forms, views, charts) that are in this App Properties Name and description of the App, custom icon (optional), unified interface URL Stay tuned for the rest of this series on building a model-driven app in Dynamics 365 using PowerApps, where we will dive deeper into the Site Map, Components and Properties.
-
Security Considerations when building a model-driven app in PowerApps
If you’re a Dynamics 365 System Administrator, chances are you’ve played around with building model-driven apps in PowerApps. By now, it’s become glaringly clear that this is the direction Microsoft CRM has headed and will continue to head when it comes to configuration and customization.
For those of you have not yet ventured into the world of model-driven apps, this blog series will introduce you to the components, security considerations and functionality to help you get started.
This series will include six articles that will help you to get to know model-driven apps and PowerApps:
Security ConsiderationsUsing the App DesignerSite MapComponentsManaging PropertiesBenefits to Your UsersSecurity ConsiderationsCreating Model-Driven Apps. When building a model-driven app in Dynamics 365 using PowerApps, it’s important to understand security pre-requisites. You will need the System Administrator or System Customizer security role in Dynamics 365, or another role with Create, Read & Write access for Model-driven app.
Accessing Model-Driven Apps. If you are using custom security roles in your organization, it is important to ensure your users have Read access to Model-driven apps on the Customization tab:
Applying security role(s) to App. Take security a step further with model-driven apps and streamline which apps appear for your users. Make sure that they only see the apps they need to see. Here are 4 simple steps to limit access to a model-driven app by security role:
1. Go to My Apps, then select Home
2. In the App box, click the ellipses icon next to the App name
3. A panel will open on the right-hand side. Select the security roles who should access the App.
4. Click Save at the bottom.
Stay tuned for the rest of this series on building a model-driven app in Dynamics 365 using PowerApps.
-
Reenhanced at User Group Summit
Reenhanced is thrilled to be speaking at thee events at the upcoming User Group Summit. If you will be at User Group Summit, be sure to stop by one of our sessions!
10 User Adoption & Training Best Practices You Can Implement TodayOrganizations of all shapes and sizes struggle with user adoption. All too often, new CRM technology is rolled out only to find that employees aren’t using it. They feel like it’s just another management tool. Join this session to learn best practices, tips and real-life examples of how organizations like yours have overcome the same struggles you are facing. This session will cover configuration, end user and training best practices and tips. “They need to learn how to use this to do their job. They will figure it out.” – Management Don’t let that be you! Come to this session and learn how to increase adoption at your organization. We will have time at the end for an interactive Q&A. Please feel free to share what has worked at your organization or ask questions to learn what your organization may be able to do better.
Join us for a workshop-type session where you can build a model-driven app in Dynamics 365 using out-of-the-box configuration. We will review components of a model-driven app, how to work with the App Designer, use the artifacts and entity assets to build your App and limit access using your organization’s security model. Then, we will be hands-on: bring your tablets or laptops and follow along. If you have appropriate permissions in your organization, I welcome you to build an App today as part of our session (in your Sandbox environment, of course!). Model-driven apps, when designed properly have the ability to streamline the user experience and simplify their journey in Dynamics 365. I will also point out limitations when accessing CRM data via an App versus the full web experience. When you leave this session, you will be equipped with the tools to build Apps for your organization (and/or possibly your first App built in the session!), including an understanding of best practices around App design.
You did it! After months of hard work, your Dynamics implementation is officially live. Users have licenses and have been trained. You are starting to see data flowing through the system. It’s a fairy tale ending! Or is it? Within weeks you start to hear users asking things such as “Hey, this is great, can we have a field over here for this?”, or “wait, I don’t remember how to do XYZ, can you remind me?” (or, worse yet, “do it for me?”), or “hey, I was listening to this podcast and they talked about this great product that does email marketing, let’s add that in tomorrow!”. The list goes on. Join this session to explore how to shift gears from project implementation to project maintenance and ensure your organization continues to push the envelope of organizational efficiency.
-
Adding a Logo or Custom Image to a Model-Driven App Tile
PowerApps are a great way for you to streamline the user experience in Dynamics 365. Available for Dynamics 365 Online Customers, creating an App is easier than ever with the PowerApps interface and drag-and-drop App Designer.
Today, let’s show you in a few simple steps how you can replace the Default Image for your App to be a custom image. In this example, I will use the Reenhanced logo. You can use your company’s logo or any image that works for the App you are building.
The default PowerApp Image Tile. This is what your users see when they select an App in Dynamics 365. 1. If your image/logo does not yet exist as a Web Resource, the first thing we need to do is add it. In a Dynamics 365 Solution File, add a new Web Resource.
Adding a new Web Resource to a Dynamics 365 Solution File. 
Name your Web Resource and upload file. Save, then Preview to ensure it looks right. Finally, Publish your Web Resource. 2. Open your Model-Driven App. Navigate to Properties in the control panel on the right-hand side of your App Designer.
3. Under Icon, uncheck the box next to Use Default Image.
Uncheck Use Default Image under the Properties tab, highlighted here. 4. In the search box above App Tile, find the Web Resource you added in step #1 and select it.
Select your new Web Resource and preview App Tile. Once you Save and Publish the changes in your App, your App Tile will be updated with the new image!
-
Change Management Best Practices for your Dynamics 365: Create a Change Management Team
To help your organization embrace the change that comes along with a Dynamics 365 project or enhancement, make sure that you have established an internal Change Management Team. This team should be comprised of champions, end user and organizational culture experts and anyone who handles corporate communications.
This is the second article in a series on Change Management in Dynamics 365 projects and enhancements. First, we talked about understanding change as a process, specifically looking at how a simple CRM project lifecycle may look when overlaid on a standard Change Curve.
Let’s look at a few areas to consider when you begin to think about creating a Change Management team at your organization.
What does the Change Management team do for a Dynamics 365 project?
This team is tasked with:
- understanding the corporate culture and user groups
- collecting end user feedback
- designing the change management plan and strategy
- designing a communication plan and execute the plans and related activities
How does this relate to the standard Dynamics 365 project team?
Your Change Management team should be involved in any regular project meetings and have an agenda item. A representative of the Change Management team should report on the action items: end user feedback (survey results), development of the change management plan and updates on the communication plan.
What roles should be represented on my Change Management Team?
When selecting your Change Management Team, you should consider participation at the following levels:
- Change Champions: These individuals will write and execute the change management and communication plans. There should be at least one expert in your organization’s culture and users included on the team.
- Change Sponsor: An executive team member who can champion the plan throughout the leadership team.
- Steering Committee: If this change is in conjunction with a Dynamics 365 project, this can be the same Steering Committee. Depending on organization size, a separate Change Management Steering Committee may be appropriate.
- Corporate/Organization Communications: If your organization has a team member who handles all communications, (s)he should be a part of the Change Management team to facilitate delivery of the Communication Plan.
More on Change Management
Stay tuned for more articles in the Dynamics 365 Change Management series. The next articles will focus on the following topics:
- Assess change readiness
- Include a Communication Plan as part of your CRM project
- Incorporate Change Management into your Training Plan
Need help crafting your plan? Contact the Dynamics 365 experts at Reenhanced today!