How We Embedded a Timesheet App for Logging Hours in Dynamics 365 CE (And What We Learned)

If you've ever rolled out time registration in Dynamics 365 CE, you know the conversation that follows. The data model is fine. The logic is fine. And yet, almost without exception, the room goes quiet, followed by some version of: "If we roll this out, the team is going to revolt. It's just too many clicks for a daily task."

I've lost count of how many times I've had that moment. Across Microsoft Dynamics 365 Field Service, Project Operations, and custom builds, time registration is the one process where standard functionality consistently lets end users down. It works, but it isn't the fast, almost-invisible experience people expect from a tool they touch every single day. So, we did what we always did: build something custom. And every time, that meant real development effort, real cost, and the architectural compromise of pulling users out of the model-driven app into something bolted on.

Then Power Platform Code Apps reached general availability, and we decided to put a proper research question on the table.

At a recent adesso Lunch & Learn, our monthly knowledge-sharing session across the Benelux, we framed it deliberately:

"How can we deliver a genuinely user-friendly time registration experience embedded in a model-driven app, while keeping development cost and effort to a minimum?"

Microsoft's Code Apps were the obvious thing to test against it. For those who haven't followed: Code Apps are a Power Platform capability that lets you build a full pro-code app (React, TypeScript, the Dataverse SDK) while still riding on the Power Platform's hosting, authentication, and Dataverse connectivity. The part that changes the game is that modern AI tooling, whether Claude, Copilot or Gemini, fundamentally lowers the technical barrier. Building a Code App no longer demands deep, hands-on React expertise. It demands knowing what you want to build and how it should be structured. You describe the outcome, iterate rapidly, and apply judgement at each step rather than writing every line yourself.

Our product, CRM Go!, is a Power Platform based solution with focused modules such as Sales and Projects. We extended it with a Timesheet Code App that runs both embedded inside the model-driven app and as a standalone application. In a remarkably short time, we had a working, embedded timesheet experience, and the result has a real WOW effect.

What we ended up with is not a stripped-down prototype. It includes:

• A weekly grid for entry: account, project, product and description per row, days as columns, running daily and weekly totals, with an automatic overtime row that flags the moment you exceed the daily target.

• A dashboard with a progress ring, monthly totals, open drafts, week progress, overtime tracking and a billability chart you can slice per week, per month or per project.

• A month overview that groups weeks with progress bars and lets you submit all drafts in one action.

• A searchable, filterable "My timesheets" list with open/submit/delete per row.

• A settings screen for default project and contract hours (40h/week, 5 days, 8h/day).

• A fully responsive mobile experience with bottom navigation and per-day tabs.

Crucially, the app reads from and writes directly to Dataverse. Submitting a timesheet automatically applies the correct billable or non-billable status to the hour lines, so the separate status-change step we used to rely on in Power Apps is no longer needed.

Because the old trade-off is loosening. For years it was an either-or decision: live with the constraints of the standard experience or commit significant budget to a custom solution. Code Apps and AI tooling change that calculation. We built a premium, purpose-built experience in far less time and at far lower cost than before, all while keeping users inside the environment they already know.

For anyone working with Dynamics 365 CE and the Power Platform, that's significant. The recurring, near-universal challenge of time registration is suddenly addressable in a way it wasn't a year ago. And for us as engineers, it signals where the craft is heading: a blend of low-code and pro-code, with AI as the accelerator in between.

For us, this was never just about building a better timesheet. It was about discovering a repeatable approach: a way to deliver the experiences clients have always wanted, inside the platform they already own, without the cost that used to make it impractical. Timesheets were the first use case. They won't be the last.

A journey worth sharing is an honest one, so a few notes from ours:

• No native mobile app support. Code Apps aren't visible or accessible within the Power Apps mobile app, a real limitation for a timesheet tool, since people want to book hours from their phone. We solved it by running the app through the mobile browser with a layout and screen size tuned for it, and as the mobile screenshot shows, the responsive experience (bottom navigation, per-day tabs) holds up well. Not the path Microsoft hands you out of the box, but a perfectly workable one.

• Premium licensing is required. Running Code Apps requires a Power Apps Premium license. They can't run under a standard Microsoft 365 license. Worth factoring into your business case up front.

• Keep a human in the loop. We strongly advise against letting AI agents run terminal commands automatically without review, especially when they have access to Dataverse and could, in the worst case, drop tables. The acceleration is real, but so is the blast radius if you remove the safety net.

• Schema changes don't sync automatically. If you change a Dataverse schema in the maker portal, it doesn't propagate to your Code App on its own. You have to manually rerun the command to add the data source, which regenerates the local models and services. A small but easy-to-forget step in the development loop.

• Expertise still matters. Tools like these dramatically compress development time, but they don't lower the bar for expertise. A result like this still rests on understanding the full development lifecycle and making considered architectural choices. AI is an accelerator in the hands of an engineer who knows where they're going, not a substitute for that knowledge.