Build a Reliable Power Apps Time Tracking App with SharePoint

TL;DR  The reliable way to track elapsed time in Power Apps is to save the start and finish timestamps, then calculate the difference. Use a timer only as a visual aid because it can stop when the app closes, the screen changes, or the device goes to sleep.

Timers look like the obvious answer when you need to track time in Power Apps. The trouble is that an on-screen timer is only reliable while the app stays open and active. Phones time out, users close apps, screens change, and epic gaming sessions have a way of outliving the device battery.

In this app, I used SharePoint to record when a session starts and when it ends. That makes the elapsed time durable, lets an active session survive an app restart, and gives you clean data for weekly totals, reporting, and future limits.

If you would rather watch the full walkthrough, check out the video here: Power Apps Time Tracking App video

Want the exact demo app? The downloadable app is available in the curated library with a paid training.powerapps911.com subscription. The article below also explains the architecture so you can understand the important decisions behind it.

Why a Power Apps Timer Is Not Enough

The timer control is useful for showing a running count on the screen, but I would not trust it as the system of record. If the user leaves the screen, closes the app, or the phone goes to sleep, the timer can stop. That is a bad foundation for tracking work time, service calls, assembly activities, meeting duration, or even how long the kids have been playing games.

Instead, the app records Now() when the session begins and records Now() again when the session ends. DateDiff then calculates the number of minutes between those timestamps. The app can disappear for hours and the data still tells us exactly when the session started.

The SharePoint List Behind the App

The hardest part was not building the buttons. It was deciding what data to store and how to structure it. The SharePoint list holds the raw facts needed to reconstruct every session:

• User: the person associated with the session. The demo uses User().FullName, although an email address or another unique identifier may be a better fit for a production app.

• When Started: a date and time value captured when the user selects Start.

• When Finished: a date and time value captured when the user selects End.

• Session Active: a Yes/No value that identifies an unfinished session.

• Number of Minutes Used: a number calculated when the session ends.

Make sure the SharePoint columns for the start and finish values are configured as date and time, not date only. That small setting matters when the entire calculation depends on the timestamp.

How the App Restores an Active Session

On app start, the app loads the current week of records for the signed-in user into a collection. It also looks for a record where Session Active is true and stores that record in a variable.

That lookup is what makes the app resilient. If the user starts a session, closes the app, and returns later, the app can find the unfinished SharePoint record. The visual timer will not magically recover, but the session itself is still alive because the real start time is stored outside the app.

This pattern is useful anywhere a process can outlast one app session. Think field service visits, machine setup, phone calls, work orders, inspections, or production steps.

Calculating the Current Week

The demo treats a week as Monday through Sunday. Power Apps date logic commonly assumes Sunday as the start, so the app calculates the Monday date for the current week and filters the SharePoint data to records that started on or after that timestamp.

Loading the filtered records once into a collection keeps the later calculations simple and responsive. The weekly total is just the sum of Number of Minutes Used in that collection for the current user.

What Happens When the User Selects Start

The Start button creates a new SharePoint record with the current user, the current timestamp, and Session Active set to true. The newly created record is saved in a variable so the app can update that exact item later.

The app also starts a hidden timer control. That timer drives the number the user sees counting upward, but it never becomes the authoritative duration. It is presentation, not persistence. That separation is the key design decision in the entire app.

What Happens When the User Selects End

The End button stops the visual timer and patches the existing SharePoint record. It writes the finish timestamp, calculates the elapsed minutes with DateDiff, and changes Session Active to false.

After the patch, the app refreshes the collection for the current week so the total updates. You could optimize this by updating the local collection directly, but reloading the filtered records keeps the first version easier to understand.

The result is a complete session record that can be summed, reported, filtered by user, or used in later business rules.

Control the Experience with Variables and DisplayMode

The app uses the current record variable to decide which controls should be available. If there is no current record, Start is enabled. If the record is active, End is enabled. After the session ends, a Start New Session action clears the variable and resets the screen.

This is a clean way to keep users on the happy path. Instead of presenting every action all the time, the app makes the valid next step obvious and disables or hides the rest.

Where This Pattern Fits in the Real World

The kids and their game time make the demo more fun, but the design is broadly useful. The same start-and-finish pattern can support:

• Tracking how long a technician spends on a service call.

• Measuring assembly or production activities.

• Recording time against tasks, jobs, or work orders.

• Tracking calls, appointments, inspections, or meetings.

• Monitoring equipment usage or any process with a clear start and stop.

The big idea is simple: store durable events first, then calculate from those events. Do not let a temporary user interface control become your only source of truth.

Common Gotchas

• Do not calculate from the timer. Use the saved timestamps so the session survives an app closure or device timeout.

• Use date and time columns. A date-only SharePoint column removes the detail you need for minute-level calculations.

• Choose a dependable user key. Full name is quick for a demo, but email or another unique value is safer when names can collide or change.

• Plan for unfinished sessions. The active Boolean is what lets the app reopen an in-progress session.

• Decide what a week means. If your business week begins on Monday, calculate that boundary explicitly instead of assuming the platform default matches your requirement.

Frequently Asked Questions

Can I use the Power Apps Timer control to track elapsed time?

You can use it as a visual counter, but you should not rely on it as the permanent record. Save start and finish timestamps and calculate the difference.

What happens if the user closes the app during a session?

The SharePoint record remains active. When the app opens again, it can look up the active record and allow the user to end the session.

Why store a Session Active column?

It gives the app a simple true or false value for finding unfinished work and controlling which buttons are enabled.

How does the app calculate weekly totals?

It loads the current user’s records from the start of the week into a collection and sums the Number of Minutes Used values.

Can I download the app shown in the video?

Yes. The demo app is available in the curated library with a training.powerapps911.com subscription.

Do I have to use SharePoint?

This video demonstrates the pattern with a SharePoint list. The important design principle is to store the start and finish events in a durable data source rather than depending on the on-screen timer.

Key Takeaways

• Save start and finish timestamps, then use DateDiff to calculate elapsed time.

• Treat the timer control as a visual aid, not the source of truth.

• Store an active-session flag so unfinished sessions can be recovered after the app closes.

• Filter data by both the current user and the start of the reporting period before calculating totals.

• Use variables and DisplayMode logic to guide the user through Start, End, and Start New Session states.

• Spend time on the data model first because the list structure determines how reliable and reusable the app will be.

Build Your Time Tracking App with PowerApps911

A time tracking app looks simple until you account for closed apps, interrupted sessions, weekly totals, multiple users, and the business rules that come next. If you want help building a solution like this for your team, the PowerApps911 team can help you design the data, build the Power Apps experience, and make the whole thing reliable. Whether the need is big or small, reach out and let’s build it together.