reenhanced

Category: PowerApps

  • Model-driven apps in PowerApps: Components

    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:

    Components

    If 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:

    1. Artifacts: Entities, Dashboards and Business Processes Flows
    2. 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 Assets

    Once 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

    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:

    Site Map

    This 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:

    1. Use existing (from a solution)
    2. Create new

    Your map consists of three components:

    1. Area
    2. Group
    3. Subarea

    Let’s first look at these three components from the back end view for System Administrators and app builders:

    Site map back end
    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:

    Site map, front end
    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 colorSitemap Designer Detail
    BlueArea
    GreenGroup
    YellowSubarea

    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

    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:

    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 Areas
    Site MapControls which areas of Dynamics 365 can be accessed in this App
    DashboardsList of any system dashboard included in the App
    ComponentsA list of entities and entity assets (forms, views, charts) that are in this App
    PropertiesName 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

    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 Considerations

    Creating 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:

    Security role permissions for model-driven app
    Troubleshooting Tip! If your users report not seeing an app or getting an error message saying the app is not accessible, make sure they have the Model-driven App Read privileges 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

    manage roles in a model-driven app

    3. A panel will open on the right-hand side. Select the security roles who should access the App.

    Select security roles for model-driven app

    4. Click Save at the bottom.

    Tip! You can hide the Dynamics 365 – custom App from all users by following steps 1 & 2 above. Clicking the ellipses on this App will give you the option to “Hide for all roles.”

    Stay tuned for the rest of this series on building a model-driven app in Dynamics 365 using PowerApps.

  • Building a PowerApp that uses Excel as a database

    Building a PowerApp that uses Excel as a database

    Part one: Reading data from Excel
    On the left, the PowerApp. On the right, the excel spreadsheet used as a data source.

    Click the image above to watch how the PowerApp updates Excel

    For 100 days, I will be doing 100 push-ups a day. I built a PowerApp to track the push-ups I have done each day.

    The PowerApp does the following:

    • Lookup a row from Excel containing today’s count
    • Calculate and display the remaining push-ups for today. Each day starts at 100.
    • Show a set of buttons for the number of push-ups completed.
    • When a button is pressed, update the Excel spreadsheet and show the remaining count. This will be covered in a future blog post

    To get this project started, I needed my data in Excel. Starting with a blank worksheet, our data starts off like this.

    Initial data to be used with the PowerApp
    Preparing the Excel file for use with PowerApps

    Before you can connect an Excel file you will need to convert the data into a table. To do this, select cells that contain your data then use Insert > Table with the selected values to convert your data into a table.

    Once your table is created, assign the Table Name and rename each of the Column Names to describe the data they contain.

    I used the following for my table:

    • Table Name: pushupTable
    • Column1: Date
    • Column2: done

    Click the image to watch how this is done

    Creating your PowerApp

    Next, we’ll visit https://make.powerapps.com/ to create a new PowerApp. We’re going to be creating a Canvas App for this project.

    Create a blank canvas app (click to view)

    This will give us a completely blank screen. You can use the Insert tab to add various items and place them.

    Insert items into the canvas (Click to view)

    To build the push-up tracker, we added the following fields:

    • Count label
    • “Remaining push-ups” label
    • 1 button
    • 5 button
    • 10 button
    • 20 button
    • 25 button
    • 50 button
    Completed layout

    With the layout completed, it’s helpful to give each field a meaningful name. You can double click the field name on the Tree view to rename each. You’ll access these within the coding portion of PowerApps so give each a name that will make sense if you have to maintain this later. You can also choose a color theme under the Home tab.

    Next, we’ll move on to connecting this to Excel. First, you need to connect OneDrive for Business and select the Excel file and table that you want to use.

    Select the Excel file through the OneDrive connector.
    Why am I getting an error about no tables in my Excel file?
    If you see this, you still need to convert your data into a table in order to use it as a data source in PowerApps. Follow the instructions here.

    Once your table appears as a data source, your excel file is now connected.

    Lookup a row from Excel containing today’s push-up count

    Let’s look at our first requirement for our app: Lookup a row from Excel containing today's push-up count

    Breaking this requirement down into steps, we need:

    • Access data from our connected data source pushupTable (The Excel table)
    • Locate a single row matching today’s Date
    • Find the value in the done column inside the matching row
    Setting variables in PowerApps
    Nearly all statements in PowerApps are function calls, which means setting a variable is possible only at the time of assignment.

    What this means is you have two ways to assign variables. You can use Set() to assign a global variable (Meaning can be accessed from any screen) and you can use UpdateContext() and/or Navigate() to create or assign local variables (visible only from a single screen.)

    Creating a global variable:
    Set(ThisIsMyGlobalVar, "This is the stored value");

    Creating a local variable:
    UpdateContext({ thisIsMyLocalVar: "This is the local stored value" });
    Navigate('Screen Name', ScreenTransition.Cover, { thisIsAssignedInNewScreen: 'Var only on Screen Name'})
    PowerApp application startup
    When a canvas app starts, it runs what is contained within App.OnStart and then displays the first screen in the tree view.

    We’ll use App.OnStart to set a global variable pushupsToday that contains the row of Excel data that we care about and then use Navigate to create a local variable Count_text that contains the text for the Count label.

    Why are we using Navigate if the first screen is shown anyway?
    We’ve chosen this path because we want to store Count_text as a local variable as it’s only used on this one screen.

    In a simple app like this it doesn’t matter about our global variable usage but in larger apps it’s a good idea to keep variables scoped to only the places they will be used.
    Accessing a specific row in Excel from your PowerApp

    In order to find a row in our Excel table we use the LookUp function. Here’s the code we’re using:

    This code looks up a Record from the table PushupTable and assigns it to the global variable pushupsToday.

    Why is my Excel date off by one day?
    You’ll notice some strange syntax in the Formula parameter of the LookUp function above. This syntax is required because of the way Excel handles Date fields.

    In Excel, when you put a Date value in a column, it is stored internally as a DateTime value. For example, if you have a value of 09/16/2019 in an Excel cell, then behind the scenes Excel stores this as 09/16/2019 12:00AM (+0000) (This is in the UTC (+0:00) timezone).

    Why is this important?
    When you pull this data into PowerApps, PowerApps will run in the timezone of the device it is run on. This means that both Date and Time values are converted into your local timezone.

    In our case, we are in EST (America/New_York) (-0400). This means that when we enter a date of 09/16/2019 and Excel stores it as 09/16/2019 12:00AM +0000, PowerApps so helpfully converts it for us as 09/15/2019 8:00PM (-0400), which is the wrong date!

    The way to fix this is to “push forward” the Date record rendered inside of PowerApps the value of TimeZoneOffSet being used by the PowerApp. This is required even if you aren’t storing Time data in your Excel records because of how Excel internally renders dates.

    Thus, to work with Date values from Excel in a PowerApp, you need to do the following:

    DateAdd(DateColumn, TimeZoneOffset(Today()), Minutes)

    Timezones are one of the hard parts of computer programming.
    Calculating and displaying the remaining push-ups for today

    After we have the record stored in pushupsToday we use this to populate a local variable that we will assign inside our Pushup Status screen. To do this, we assign a Context parameter inside of a call to the Navigate function. Note that the call to Navigate isn’t required but is used here so we can push the variable into the right area. It’s not possible to create local variables from within App.OnStart any other way.

    Here is the full code we’ve used in our App.OnStart:

    App.OnStart
    Set(
        pushupsToday,
        LookUp(
            PushupTable,
            DateAdd(
                Date,
                TimeZoneOffset(Today()),
                Minutes
            ) = Today()
        )
    );
    Navigate(
        'Pushup Status',
        ScreenTransition.Cover,
        {
            Count_text: 100 - pushupsToday.done,
            loading: false
        }
    );
    Assigning dynamic label text

    We’ve assigned a local variable called Count_text with the text that we want to display on the big label. To assign the label to show the value for this, do the following:

    Assigning the remaining push-ups to display (Click to watch)

    Why are we using a variable to hold the text?
    When we assign Count.Text to a variable it will update whenever the value of that variable is updated. In a future blog post you’ll see how we use this to always display the most recent data from Excel so that our push-up count is always accurate.

    Putting everything together

    The first step in our PowerApp is now done. We are showing the remaining number of push-ups for the current day on top of the app. In coming blog posts we will cover how to enable each of the buttons and how we’ll use what we did today to dynamically update the remaining count so it is always accurate.

    As a final walkthrough, lets run our app and show how all of the moving pieces are connected. View the image below to see how the values are captured from Excel and then used to display inside the app.

  • Adding a Logo or Custom Image to a Model-Driven App Tile

    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.

    default app tile
    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!