Your cart is currently empty!
Tag: dynamics 365
-
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!!
-
Quick Create Opens The Wrong Form
Dear Software Rescue Specialists,
Mr. Slow Create
One of our Dynamics 365 (On-premise v9.0) users is having a problem with their Quick Create Forms.
Whenever they click to open a Quick Create form from the top navigation or from a sub-grid, the modal that opens shows me the full default form instead of the quick create.
This user is using Google Chrome on a Windows 7 installation.Dear Mr. Slow Create,
We’ve seen this issue happen when users are using Chrome on Windows 7. The solutions we’ve identified at this time are as follows.
On further digging, we were able to identify this with an error message in the developers console:
Cannot read property 'firstChild' of null
Our investigation discovered no quick fix so we’re diagnosing this as a browser incompatibility specific to Chrome on Windows 7.
Thanks,
Nick
Software Rescue Specialist -
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.
-
Planning for Dynamics 365 License Changes
Understanding how things used to workPrior to this change, Dynamics 365 was licensed on a selection “One Size Fits All” packages. Depending on what applications and features you needed, your accounts were licensed according to different bundles that would provide as much or more than needed for your account to function.
For example, if you needed to access Field Service and Sales, your only option was to purchase the Customer Engagement Plan, which would also give you access to Customer Service and Project Service Automation.
Now its a pay-per-app modelWith the changes launched on October 1, pricing moves to a Base plus Attach model for licensing in which a Base application is selected and then one or more Attach licenses can be added to it to determine costs.
In this new model, many businesses can save costs in some areas and see price increases in others. Due to the way licensing is assigned, these costs may not always be clear.
Announcing the Dynamics 365 License PlannerIn order to help you understand how these licensing changes impact you, we are releasing a Dynamics 365 License Planner tool to help you build your license plan and understand how your users will need to be licensed upon renewal.
Click the image above to visit the planner and start planning your license renewal today.
Dynamics 365 License Planner -
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.