If you’ve been using computers in the not too distant past, then you may remember those dreadful moments where you’ve made some important changes to a file and see it fizzle into thin air due to a power outage or inadvertently closing an application.

Microsoft first introduced AutoSave in the July 17 update (version 1707 build 8236. xxxx) for Office 365 subscribers. Since then, we’ve seen AutoSave become somewhat of a de-facto functionality, particularly in web-based apps, such as Word Online, Excel Online, PowerPoint Online, and OneNote. In fact, these apps don’t even have a save button and rely implicitly on this functionality.

With the surge in the Power Platform usage, I often get asked if there are ways to create a similar experience in Canvas apps. The short answer is yes, but as with any other development, the way in which you implement it will depend on your specific needs.

In this two-part blog series, I describe two different approaches for dealing with AutoSave in Power Apps — timers and screen transitions. This article will focus on the timer approach.

AutoSave using Power Apps, Part 2: Screen Transitions

The Timer Control

As you can imagine, AutoSave employs some form of an internal timer that kicks-off periodically and performs its actions. So, it makes sense to use a similar mechanism for our Power Apps. The Power Apps Timer has several properties that are required to achieve the AutoSave functionality

• Duration — How long a timer runs in milliseconds. The maximum is 24 hours expressed in milliseconds. Default is 60 seconds. See my notes below on defining the duration
• OnTimerStart — Actions to perform when a timer starts to run. This is where the expressions are entered to save the work.
• OnTimerEnd — Actions to perform when a timer finishes running. Only necessary if there are additional expressions you wish to run after the save operation completed.
• Repeat — Whether a timer automatically restarts when it finishes running. Set to true
• AutoPause — Whether the timer control automatically pauses if the user navigates to a different screen.
• AutoStart — Whether the timer control automatically starts to play when the user navigates to the screen that contains that control. Set to true
• Start — Whether the timer starts.

Duration

When choosing the timer duration, you need to consider how long it will take to complete the save operation. This is particularly important if the save operation needs to return some data to the app or if you are looking to lock controls during the save operation. Another consideration is for the number of API calls that are being made.

If the app will be run for short amounts of time and save operations are simple and don’t impact the app itself, you can afford to make the duration shorter (consider how long it takes for the user to complete the work on the screens). However, if the app has complex logic, needs to write data back, or runs for long amounts of time, then you should consider longer durations. The risk in the longer durations is the potential data loss if the app closes or looses connections to its data sources.

A way to reduce the number of API calls and time to save is to keep track on whether any of the values have actually changed. If not, then there is no need to perform any save action.

AutoPause

Depending on the nature of your app, you may want to save all the data all the time back to the data source or segment it screen by screen. To make this decision, you need to consider whether there are mandatory fields or dependencies across the screens.

Considerations

Implementing an AutoSave mechanism in your Canvas Power Apps can be achieved in a straightforward fashion using the built-in Timer control. When configuring it for your specific app, you need to think about how often the app will perform the save action and whether it’s global to the entire app or local to a specific screen. Other considerations are on the data source side. If the data source is keeps a history (such as SharePoint lists), then the mechanism could result in many versions. If the source is set to keep on a specific number of versions, you may end up overwriting older versions that hold valid data with many drafts while the app is open.

Originally published on Medium