Consistent Y-Axis in Model-Driven App Charts

This week I faced a very old school problem with model-driven apps from the days of working on-premise with Dynamics CRM, I needed to show two different series on the same graph, but every time I would view the chart it would show me two different scales on the same Y-Axis!

As this chart was for the purpose of comparing values, this makes the out-of-the-box chart meaningless as in some respects, smaller numbers look bigger than their counter part as shown below with test data in my development environment.

A screenshot of a model-driven app chart with two different Y-Axis scales for the same type of data.
Note that the y-axis reference on the left has a higher increment for each bar in comparison to the right y-axis.

We can resolve this with a few steps by editing code, and here’s how.

Step 1: Back up your environment

Before we get started, please note that Microsoft have gone a very long way to make solutions a no-code option for deploying components and that it is not recommended to edit solution files unless the requirement cannot be fulfilled any other way, and you are absolutely confident in how solutions are composed and deployed.

Always back up your database before significant operations, and seek support from peers if you are uncertain. It’s also worth considering how impactful this change is, and whether the effort vs. benefit stacks up in the correct way.

Step 2: Create a temporary solution file

In order to make sure that our changes persist from development to production, we will need to re-import our code changes back into the source environment once complete. This is so that the changes are recognised every time we export from source and deploy to target in the future, otherwise you would need to make this change every time you deploy to a new environment in the future which carries risk due to the frequency of this activity.

A screenshot of a user creating a new temporary solution file.
This helps us to target the components that we need to change that otherwise live in another solution, and therefore reduces risk considerably.

Step 2: Add your chart(s)

When we add existing components, we’ll need to locate the Table and its associated Chart components for change.

A screenshot of a user selecting multiple existing charts to add to their solution.

Again, let’s make sure that we only add what we need here.

Step 3: Export an unmanaged copy of the solution

As we need to edit the code that sits within the solution, we must export it so that we can make the changes and re-import it here later.

A screenshot of a user selecting the Unmanaged option for the solution export.

By selecting Unmanaged, we retain full control over the customisations once the solution is re-imported, which is important as we probably want to keep the changes but remove the solution file later on.

Step 4: Unzip your file and make the change

Solution files download as .zip files, so we need to extract the files before we can work on them. When you extract the files, you’ll see three files:

  • [Content_Types].xml
  • customizations.xml
  • solutions.xml

We now need to open up customizations.xml in our favourite code editor, preferably Notepad++ or Visual Studio Code. Search for the word ‘Secondary’ within your code, and remove the YAxisType variable. You will have one of these tags for each chart that you’ve added with multiple Y-Axis, and in this instance I have two due to the two chart components that I selected earlier.

A screenshot of a user editing the customizations.xml file in Visual Studio Code.

Original code:

<Series ChartType="Line" IsValueShownAsLabel="True" BorderWidth="3" MarkerStyle="Square" MarkerSize="9" MarkerColor="37, 128, 153" MarkerBorderColor="37, 128, 153" YAxisType="Secondary" />

Amended code:

<Series ChartType=”Line” IsValueShownAsLabel=”True” BorderWidth=”3″ MarkerStyle=”Square” MarkerSize=”9″ MarkerColor=”37, 128, 153″ MarkerBorderColor=”37, 128, 153″ />

Step 5: Zip up the files and re-import

Now this is where we need to be extremely careful, we need to select the three extracted files and compress into a .zip file.

At this point in time, your Windows device will ask for a name for the .zip file. You should make sure that the name of your file within this folder is exactly the same as the original file name exported from your PC. As long as you zip these files up anywhere other than the same location that you downloaded the .zip file too, you will have no problems doing this, and you’ll then be able to go back to your browser to import the newly compressed .zip file.

A screenshot of the newly modified .zip file being uploaded to the environment.

And there you have it! I have mentioned this just a few times before, but remember that this is a relatively complex and risky operation that should be executed with focus and confidence. I have the luxury of working on on-premise versions of Dynamics “CRM” well before some Power Apps developers were out of secondary school, but if you aren’t so sure, please do reach out to me or to someone else who may be able to help with the more technical elements of this activity.

A screenshot of the final result, showing one y-axis for both lines in the graph.

Now that you’ve seen the results, you are safe to carefully remove each component from your temporary solution, before finally removing the solution itself.

The Power Of A Great User Story

For anyone that personally knows me, they will know that I am absolutely obsessed with getting User Stories right!

On the face of it, it may seem impossible to deliver part of a business process from one single sentence, but user stories are one of the best tools you can use, right from your initial engagement through to post go-live support as long as each part adds value.

What is a User Story?

User stories can help us to define a requirement for a business user or process that needs to be included within a project or product to ensure success. Generally speaking, user stories follow the following format:

As a [persona], I want to [achieve], so that I can [action].

That is all, one seemingly simple statement. Some may feel that writing user stories are a waste of time in an agile project, particularly as an agile project is supposed to deliver technical outputs quickly, however, user stories can actually speed up the turnaround time of the solution, providing that we pay particular and collaborative attention to it’s construction.

The Construction

Let’s take a look at what we want to achieve from each part of the User Story and how we can add value. As I am a Power Platform and Dynamics 365 Customer Engagement consulting manager, I’ll be using an example from Dynamics 365 Customer Service.

As a [persona],…

It would be easy to write “As a user…” here and be done, but this doesn’t tell us anything except that this isn’t an automated process.

Particularly in the Power Platform and Dynamics 365 space, the functionality and security model can span multiple applications, so perhaps we can describe the user and the way that they’re accessing the product or feature.

As a Customer Service Representative accessing the standard Customer Service Hub application,

From the above, we can understand that:

  • The user definitely needs a Dynamics 365 Customer Service license if existing licenses do not allow access.
  • The user is likely to use the standard Security Role provided due to the persona’s role.
  • The user is not expecting a tailored sitemap experience, as they will access the application through existing means.
  • The experience is triggered by end user behaviour rather than automated processes, until we discover more about the rest of the story.

I want to [achieve],…

We now want to ensure that we describe the Customer Service Representative’s objective in this part of the user story, so that we can start to understand our scope and design our solution.

As a Customer Service Representative accessing the standard Customer Service Hub application, I want to see all of my priority ‘1 – Blocker’ Cases in a separate list sorted by oldest to newest creation date,…

To add to our previous understanding, we now know:

  • The user has a focus on Cases that need the highest amount of attention, and these should be categorised by priority. Right now we don’t know the full list of priorities, but we can add that as a known unknown in our design.
  • The user needs a new view for just the Cases categorised by this priority, and the out-of-the-box priorities are High, Medium, Low. It seems like we need to carry out Column and List configuration in Dataverse here.
  • The List that we configure needs to include the Created On date, and needs a sorting on this Column too.

So that I can [action].

The primary purpose of this part of the user story is to justify the action through behaviour. Some consider this part of the user story optional, however I like to ensure it’s included in every user story as it can significantly change the estimate required to deliver.

This part of the user story doesn’t just have design benefits, but it can also help us prioritise the user story against other user stories in the backlog when we are working in iterations or sprints.

As a Customer Service Representative accessing the standard Customer Service Hub application, I want to see all of my priority ‘1 – Blocker’ Cases in a separate list sorted by oldest to newest creation date, so that I can ensure that we do our best to meet our 1 day ‘solution or workaround’ Service Level Agreement (SLA) for blocked customers.

We now know why this design is so important, and we can deduce the following:

  • The organisation makes promises within their agreements with customers to ensure that business processes aren’t blocked for more than one day, and this needs to be a core emphasise within the design.
  • We can ask if we can further improve the design by introducing system triggered Service Level Agreement functionality.
  • Most importantly, another business initialism has been cleared up, by clarifying why the customer keeps writing SLA all over their documents!

Isn’t This Too Much Detail?

Not at all. It’s unlikely that we will every get to this level of detail within one round of workshops, however, through refinement during iterations or sprints, this can tell us almost exactly how we need to build a feature. It will also help us more accurately estimate our delivery and provide a higher chance of passing tests after deployment.

One phrase I frequently hear is ‘we don’t need to worry, it’s just out of the box functionality’, but from one sentence regarding standard functionality, we have been able to arrive at 10 conclusions with definitive design that definitely carry an associated effort.

I am sure others reading this will find additional conclusions too, and this is the great thing about user stories – multiple perspectives can help to narrow down exactly what the client is asking for, and ultimately lead to a higher quality delivery.