Skip to content
Brad Cannell edited this page Mar 8, 2024 · 6 revisions

This wiki is where we will track notes about power automate flows. Not so much what changes we make -- those will be issues -- but, why we make the changes we make. Importantly, this wiki will also serve as an instruction manual.

  • The README will no longer contain much information -- just links to the wiki.

  • The Power Automate Flows project board. This is where we will track specific changes we want to make to a flow. For example, "Figure out why all planner tasks say 'due in 7 days'.".

  • The Development Projects project board. All of the production flows will be listed on this board. The cards with the flow names on them will show us how the flows fit into the larger landscape of all development projects. Additionally, they will be categorized by working status.

    • The cards (issues) on this board are where we should make notes about the flow's purpose (i.e., the description on the Power Automate page for that flow), development notes, and relationships to other flows.

      • Development notes are not tasks. They are the why, not the what.

      • Previously, this wiki contained pages that grouped together similar flow types (e.g., My Planner Flows). This caused us to have to maintain information about flows in as many as three different places -- the flow's page on the Microsoft Power Automate Website, the wiki, and the Development Projects project board. That's way more complicated than it needs to be. Now, we will just track flows on the Development Projects project board. Don't overthink it.

    • To view only the Power Automate flows, click in Filter by keyword or by field bar and type label:"Power Automate".

TOC

Instructions

This section contains instructions for creating, updating, maintaining, and deprecating flows.

Ideas for new flows

If you have an idea for a new flow, you should:

  • Add it to the Ideas/Eventually/Maybe column of the Development Projects project board.

    • If we plan to start work on the flow immediately, it's fine to create the card (issue) in the Active Development column.
  • Title the card PA - Create <flow name>. Later, after the flow is created, we can remove the word "Create" from the title.

  • Add a basic description of what you want the flow to do and why.

    • It's fine to also quickly jot down a task list in the card (issue). Don't overthink it.
  • If this flow has relationships to other flows, go ahead and add that information to the card. We can also link to other cards (issues) using the hashtag syntax.

Creating flows

When you are ready to start working on a flow:

As you experiment and learn new things, make sure to add them to the appropriate My PA Documentation section of this wiki.

Updating flows

If you want to update or repair a flow:

As you experiment and learn new things, make sure to add them to the appropriate My PA Documentation section of this wiki.

Deprecating flows

Sometimes, we no longer need flows or we replace them with a different flow. When that happens:

  • Move the flow's card to the Deprecated/Abandoned column of the Development Projects project board.

  • Add any relevant notes about the flow to the card (issue). For example, why it was deprecated and what new flows, if any, replaced it. This can help prevent us for having to learn the same lesson twice in the future.

Why are we going to all of this trouble?

Great question! I'm thinking that to myself as I'm typing this. And, I may later decide that this is way more complicated than it needs to be. However, here are the reasons I started down this path:

  • Learning and using Power Automate is still new to me and I'm still making lots of mistakes/changes.

  • I need to be able to track those changes somehow. Power automate doesn't have a versioning system at all (that I'm aware of) and it doesn't have a very good system for commenting code.

  • I could track these changes in the cards on the Development Projects project board, but that would require me to use that board differently for power automate projects than all the other projects I'm tracking on that board. For example, I don't put specific changes I want to make to the freqtables package on that board.

    • Having said that, don't overthink it. Power Automate flows are different than R packages. They are more self-contained. Use the simplest method that will effectively and efficiently get the job done. Spending hours updating documentation in multiple different places is not a good use of your time.
  • Additionally, I need a place where I can write down lessons learned. Because Power Automate uses action blocks instead of code like R, there isn't an obvious way to maintain development notes directly in Power Automate. For example, I have an R folder on my computer for keeping little tips and code snippets, and I can put them under version control. Power Automate doesn't really have anything like that built in. I'm hoping the system described above will work. I'm sure it will take some tweaking over time.