>> Do you love building Power Platform solutions
but you hate having to write technical documentation?
Well, Rene Modery has a solution for you.
Stay tuned for Low Code Revolution to
see how you can automatically generate
technical documentation for
your Power Platform solutions. Stay tuned.
[MUSIC]
>> Hey everyone, welcome to
another episode of The Low Code Revolution.
I'm your host, April Dunnam.
Today, we're joined by Power Platform MVP,
Rene Modery. Welcome to the show Rene.
>> Hi, Good evening, April.
>> Thanks. Rene, you build a pretty amazing solutions to make
building Power Platform documentation of
our solutions much easier.
Can you share a little bit first about yourself and then what
inspired you to build
your solution here for technical documentation?
>> Absolutely. My name is Rene Modery.
I'm an Office 365 MVP since 2012,
so quite a long time.
Originally, coming from the SharePoint Office
365 space, but obviously,
Office 365 being such a very bigger platform,
it meant that at some point,
I just have to touch the Power Platform as well,
and partially because of
personal reasons because I wanted to do things partially
because of professional reasons
because from a professional point of view,
I'm currently the Power Platform tech lead
at a very large organization
with around $140,000 employees globally so there's a lot to do,
and a lot of things get done.
Basically, all that led also me to think
about the things that I'm
doing partly initially in a personal way, but also,
from a professional point of view then led me to think
whenever there's an app being built
or flow being developed, or something like that,
or a solution which contains multiple of such components,
part of it gets basically documented.
Often, you've got your manually created documentation
that explains why you,
for example, built a specific app?
What's the purpose for it?
The business case behind it,
and all those things,
partially also document it's called the technical aspect or
maybe rich environment is the app located in
or which service accounts are getting used,
which other systems are getting used, etc.
But I did realize that, for example,
a lot of times you build something and it's there,
and when you have to revisit again after some time,
you might have to think about,
how many screens went into that or what variables are in there,
what are they used for?
Those things that really led me then to thinking
about there should be an easier way to actually look at,
for example, an app or a flow and figure out
from a technical point of view what's happening inside it.
That's why I then thought,
I'm going to develop a test app
to see whether I can actually document all
that that's inside their order flow
and see if I can actually then pull out relevant information,
create some documentation for it,
and that documentation should then ideally help
me basically get a better understanding,
for example, about
the app that are built or the flow that are built,
etc, and innovate.
The idea is not just looking at it afterwards,
but potentially also, for example,
handing it over to other people
so that they can then see what's happening.
Could use case for example from
a professional point of view is that
one team builds an app but
another team is supposed to support it,
so what are some documentation that best handed over?
Usually additional information about what's happening
inside your solution is always malleable and helpful.
That's basically led me [inaudible] then to
developing PowerDocu to make sure then
that this documentation that is
hopefully useful for people in different ways can get generated
quite easily without spending hour
of writing comments into a document
so and always having the updated
whenever there's a newer version of your app flow but rather,
simply said, run a small app,
click a button and you've got your updated documentation.
>> I love it. I think you either love creating
technical documentation or you're
in the camp like me and you hate it.
It's really cumbersome,
but it's a necessary evil to have to create
that documentation because it's going to help
a lot of people along the way.
I'm sure we have all been there.
I know I have where you're coming in after the fact to
have to update or manage a solution someone else has built.
In that case, if you don't have
good technical documentation it's
just going to make that even harder.
I love that you've built something
that produces content for us and
makes it easier to get
high-quality technical documentation so
that we can share it with others.
I'm really interested to see
a demo of how this works. Can show us?
>> Yes, absolutely. Let me just bring it up here on my screen.
What we have is the application itself.
It's relatively simple as mentioned.
I guess not that you have to configure
a lot of things to get started,
rather you download the app, you run it.
You might initially then just for example update
your connector icons so that the app can then use
updated icons to use
inside the documentation that gets
generated, and that's about it.
Next step for me then is to select
the app flow solution I want to document.
The idea is then you've got
your full solution which contains then again,
multiple apps or flows
or you might have just exported an app or flow.
Either way basically you exported
something and you then want to document it.
All you need to do is then select what you want to document.
I'm just going to go ahead and document
my FullWeather and my LearningApp,
which are Flow and Canvas app respectively.
Just clicking "Open" and it just gets processed.
PowerDocu checks, but inside those files that are provided.
We discovered there is flow in the first one, for example.
Decided to create some crafts and avert documentation,
and then each was done with it.
Continued again with the next file which
is Canvas app inside a solution.
Did the same thing again,
documented it and it's done.
It was quite fast as you see.
It's talking about two, three seconds.
Here we've got one second bound here so it's
probably happening usually quite fast,
unless we've got a very complex flow app.
Just to show you then what actually gets generated.
What we then have here,
and I'm just switching over here,
it generates the documentation in
specific folders named after your app or solution of flow.
They're just looking for some at my floor documentation.
I mentioned it generally some crafts
which you can also see in preview.
But let me just opened up a Word document
because there are actually also used in here.
Basically the documentation as mentioned tries to get
as much technical details out of the exported flow as possible.
It gives you some high level information at the very top.
We see here, for example
what it's actually getting used here right now.
We get an overview of the flow itself.
That's really the top level actions
that are happening inside the flow.
Be jumping to the connections that are used as part of the flow.
That's obviously important to figure out
what else is the flaw connecting to?
well, that is obviously visible when you open
the flow for example in the maker studio.
It's good to still have a document separately here as well.
Continuing down, you can see it
can be document variables which I think
is really helpful especially when you've built along big flow,
you define one variable somewhere which
might used in a lot of different locations
and you need to figure out where
so I've realized this is quite helpful.
I can see folks on my calendar events. It's not checked.
I see how it is initialized.
You can see basically there's empty fields.
I know where it is actually getting used in V,
which actions inside my flow.
More details about that trigger
and the actions are also documented
so then we can see for
each action in detail again what's happening.
Sometimes that might be quite readable.
My composed section here I can see,
for example, we can see all composed.
It's actually sitting some values here.
Sometimes it's a bit more tricky to
read like the calendar view of events,
again, that's coming from the technical exported.
Flow definition you could say.
There's a lot of things in here usually
which are not really easy readable.
Here's a calendar ID which doesn't mean much.
I know for myself right now that's
my own personal calendar it's using,
but that's just in detail how it is here right now.
Plus at the end and we've got here
that detailed image of the flow,
so not just see the high level of what's happening,
but also we can see much more detail,
going to zoom in, for example,
what's happening in each action plus in
each sub action, let's call it.
Folks on my Team may apply to
each everything that's happening inside here.
As you can see, this really quite helpful as well.
If you just want to say, I want to take a screenshot of my flow,
but my flow is huge.
You could actually just use PowerDocu to generate this output
and then share it with others print it to whatever's with it.
Plus you see also here the I
think the connector icon that is used.
I can see here it's using the calendar here.
Some other MSN,
what API here and see additional [inaudible].
Just to show quickly how that flow actually looks like.
That's actually default flow template,
even me with a list of upcoming calendar events.
You can see here again variables getting initialized.
First action, we've got our Apply to each and
everything else happening inside, same thing.
All that basically gets taken out of
here and put into a Word document.
Four, let me just quickly jump
over to the other one that we documented.
>> I'm sorry to I had to say.
I probably wonder how much it was able to
generate for us in just two seconds there.
The diagram alone, like you said,
oftentimes our flows can get really complex.
Just having that screenshot there of
the flow and then all of that formulas,
this I think is important to know this is
a good backup really of your formulas.
If anything happens to your flow,
it actually make a change,
you have that compose formula that you can just copy it from
your documentation now to
fix if you accidentally delete something too.
>> Exactly, and especially when,
for example, your app flow gets much bigger.
You're not talking about relatively simple things here right now,
but a friend of mine had a flow that had,
I forgot how many actions,
but I think it was more than 200.
It even takes 60 seconds not just to generate the documentation,
but having the big diagram showing her basically what's
happening is extremely helpful because when she opens the flow,
it's obviously quite small everything that she sees.
Here she can zoom in, she can share it and with
other stakeholders, potentially et ceteras.
Not many different used cases for it.
>> Anyway, so coming to
the document or the documentation for our Power App.
This is a simple Power App that I developed for my kids.
The idea was every now and then I come back
to it again to make some small changes
and sometimes when you figure out again,
"Okay, how did I actually do things?"
Etc. You are going to see it's similar to what we saw in the flow.
There is some channel information at
the top, including some statistics.
I immediately see how simple or complex map is right away.
I can see four screens.
There is not lot controls.
Good number but not overly large,
plus some additional information about variables,
collections, data sources, resources.
Next then obviously my variable so I can see
what global variables are used plus where they are used.
Really which control is using
a specific variable and on which property?
I know that final score is used for the final score label
in the text property key as an example or the OnSelect properties.
Therefore in for labor and safe score,
same thing then for a context variables plus,
I'm going to scroll down
but also some information about collections.
It also have some information about data sources that we use.
Again, there may not be a lot of information.
For example, if I scroll down a bit more,
we can see there's some information coming in from the Dataverse.
Doesn't tell me much here.
In a future update I
hope to have maybe some additional information
about the Dataverse tables or so but
right now I'm focusing only on the app itself.
Let's see what could be happening in the future.
Resources documenting obviously [inaudible] order.
Resourcing the app, that can be quite
useful as far as not just saying, "Oh,
there are some images in there, but as you can see,
they're getting embedded hues,
as far as directors [inaudible]."
I've got some images.
Now the nice thing is,
what I always wanted to see is
when I go into the PowerApps Maker Studio,
I can see on the left-hand side
my mini overview of
the different screens or the controls that are there.
I'm simply there trying to replicate that experience here.
Documented as well so it's easy
to see now what is on my home screen,
what's on my play screen, etc.
What controls do I have here?
Not just listing it,
but also trying to make it as nice as possible in a way.
Good. Additionally here what I have as much as one document,
but I've also got a more detailed document.
The difference between these two is for the current document,
I'm stopping that and I've stopped one second late.
Forgot one important thing.
One nice thing I just added some information
about from which screen do we navigate to which other screens?
I know from my home screen,
I only navigate to the quiz screen
from that and you can see what else is happening.
Most screens go back to the home screen and
the score screen will go back to the quiz screen etc.
It's really just making it a bit clearer
how do your different screens interact with each other.
>> I love it. That's really cool.
>> The last thing is mentioned so that
detailed document contains everything that
the normal document contains plus it
contains additional information about the controls.
When I say additional information,
that really means every single control and where it is stopping to
respond right now because it's
just processing the big document. As you can see.
>> All the properties, okay.
>> All the properties get documented.
The colors I document in a more colorful way,
but everything else just gets more as output directly.
It's useful when you've got, for example,
something like the items I can see directly what I set here.
I can easily then also search the document for
certain things that I know are somewhere in there.
But the idea is then everything gets documented.
That might sometimes be a lot.
Depending on what we look at is called [inaudible].
I don't have anything specific here right now.
But as you can see that it is always very detailed.
Sometimes maybe a bit too much
if it's a default value is always in there.
But the purpose is really to say,
"My current version of
my app this is basically how it was defined."
I could easily say, "Where do I
use for some specific color within
my app or where do I
use certain other reference to another control?"
All this is available in years, all of them,
which might also be something I'd want
to sometimes review and figure out later as well.
>> Well, that's amazing.
>> It's working, I simply said.
For solutions again, if I had a whole solutions in documents,
everything in the solution of everything,
meaning Canvas apps and flows,
all individually, but other natural rate,
that's the current state of things.
>> I love it. From the PowerApps side,
I loved that first screen that you had,
where broke down how many data sources
and the controls and everything that you have in
the app because oftentimes when we're doing
maybe a mini app review,
performance review of the app,
we're looking for things like that.
How many total data sources do you have?
How many controls to see if there's room for optimization?
Your documentation, it's going to
provides that for you right off the bat at the front.
So many great things and even going as
deep as to seeing all the properties of the control.
Just makes life so much easier to be able to
have this documentation on hand to give it to
people that are going to be able to move
the solution and edit that going
forward and then have that as a backup too.
It's just a really great solution.
Is that a console applications?
Did you built that in a C-Sharp or something like that then?
>> Recording Dotnet pillars or using C-Sharp for it,
which also means it's hosted on GitHub.
Let me just click to open that.
Meaning everybody can look at the source code.
Ideally, if people want to improve it,
have some recommendations, some ideas people can come in here.
They could update the source code if
they wanted to or submit a pull request.
They can add a discussion at an issue item so
the idea it's not just
my own solution and I just hand out to find the state of things.
But if somebody sees something that can be improved in any way,
for example, I'm happy to listen to
other people to see is there something that I didn't think of?
Is there something that could be improved over time, etc.
That we can then see whether that can happen in some other way.
You can just throw me your or somebody else in a way there.
For example, we've just seen work documents.
Next step right now, which is currently in progress
is generating documentation that is smart down based.
Instead of just having a web-based document,
you've got marked down based documentation,
that it can then focus on upload into GitHub,
into Azure, DevOps or other similar systems so
that you've got the web-based documentation available as folder.
>> I love it. That would be
great to have that the markdown version.
I love what you build just
because we talk a lot about fusion development on
the show and how code-first developers
and low code dads can work together.
It's just a great example of using a code-first tool
to be able to help generate documentation for your local solution.
Love it. Make sure you check out the Power Doc,
you GitHub there, download it.
Give it a task, see her work to you.
Thanks so much for coming on the show Rene.
>> Its been a pressure. Thank you very much.
>> Thanks. We'll see you next time on The Low Code Revolution.
[MUSIC]