Two Ticks, Two Different Things: Is a Power Apps vs WorkMobile Feature Comparison Actually Useful?

By Colin Yates, Director, WorkMobile

Software comparisons nearly always end up in a table.

One product has a feature, so it gets a tick. The other product has the same feature, so it gets a tick as well. Before long there are two columns full of ticks and the natural conclusion is that the products are broadly equivalent.

I have never been particularly convinced by that way of comparing software. Having spent many years developing applications, I am usually more interested in what sits behind the feature than whether it can technically be reproduced. Two identical ticks can describe two very different things. One means “you can build this”. The other means “this is already built”.

A feature list tells you what is possible. It does not always tell you what you are signing up to.

Power Apps and WorkMobile are a good example. Microsoft Power Apps is a broad low-code development platform for creating business applications. WorkMobile is the platform we have developed specifically for field and operational workflows, where work is issued, information and evidence are collected and completed records are returned to the office.

There is enough overlap for a comparison to make sense. Both can be used for mobile forms, approvals, evidence capture, reporting and other operational requirements. But putting a tick beside those features in both columns hides an important difference in how you get there.

A tick does not tell you what sits behind the feature

Take something as familiar as photographs.

Power Apps can capture photographs. WorkMobile can capture photographs. Put them into a comparison table and both products get a tick.

But the requirement is rarely just “take a photograph”.

The image may need to be linked to a particular job or question, remain available while somebody is working offline, carry location and time information, be marked up to show a defect and appear in the correct place when the completed report is produced.

With Power Apps, each of those requirements has to be designed into the application. With WorkMobile, they are settings. A form can be configured to insist that photographs are taken there and then using the device camera, or to allow images to be chosen from the gallery where that is appropriate. The location can be physically embedded into the image itself as well as recorded in its metadata, so the evidence still shows where it was captured even after it has left the system. Users can annotate photographs to highlight a defect or explain what the image shows, and signatures, GPS and timestamps are standard parts of the platform.

That one decision, whether a photograph must be taken on site, can matter a great deal. An image chosen from a gallery could have been taken last week, or somewhere else entirely.

For many inspection and compliance processes, the difference between those two options is the difference between evidence and an illustration.

The same applies to job allocation. Power Apps can certainly be used to create an application that allocates work, tracks its status and presents it to mobile users. In WorkMobile, job allocation comes with a full scheduling calendar as standard. Office staff can see who is working where and when, allocate or reassign work, e.g. drag-and-drop rescheduling, team views etc. and follow job status as work progresses. In Power Apps, a scheduling view of that kind is something to design and build, along with the logic that sits behind it.

Both products can therefore receive a tick for job management, but those ticks describe two different things. One tells you the capability can be created using the platform. The other tells you it is already part of the product being configured.

That distinction is much more useful to me than the tick itself.

Offline working is another good example

Offline capability is particularly important in field applications, as I discussed earlier in this series. Power Apps supports offline working, although the way it is implemented depends on the application architecture, data source and configuration.

WorkMobile was designed around mobile field use, so offline working is part of the mobile product. Records can be held locally and synchronised when connectivity returns.

Again, both products can appear under the heading “Offline working” in a comparison table. What the table cannot easily show is the difference between designing the offline behaviour of an application and configuring a workflow inside a product where the underlying offline framework already exists.

It is a small distinction on paper, but a meaningful one when deciding what work an organisation actually wants to take on.

A more honest comparison table

If I were building a comparison table, I would replace the ticks with three labels: built in, configurable or must be built. The same features then tell a rather different story.

Requirement	Power Apps	WorkMobile
Capture a photograph	Built in	Built in
Force photos to be taken on site, or allow gallery selection	Must be built	Configurable
Location embedded in the image and its metadata	Must be built	Configurable
Photo annotation	Must be built	Built in
Photos linked to the correct question in the finished report	Must be built	Built in
Job allocation and status tracking	Must be built	Built in
Full scheduling calendar	Must be built	Built in
Offline working	Configurable, depending on architecture and data source	Built in
Custom interface and bespoke application logic	Built in	Limited
Deep integration with Dataverse and Dynamics 365	Built in	Via Power Automate and SQL Server

Neither column is all ticks, and that is the point. Power Apps wins where the requirement is unusual or needs to sit deep inside the Microsoft environment. WorkMobile wins where the requirement fits a field and operational structure that already exists.

Flexibility also needs some context

Another word that appears regularly in software comparisons is flexibility, and it is easy to assume that more flexibility must always be better.

Power Apps clearly offers broader flexibility. An organisation has much greater control over the application, its data, the interface and the logic surrounding it. If the application needs to behave in a very individual way or sit closely within a wider Microsoft environment, that freedom can be extremely valuable.

WorkMobile has more boundaries. Its flexibility sits within an established operational structure based around jobs, forms, mobile users, evidence, approvals and completed records.

I am quite comfortable saying that Power Apps gives you more freedom over the application itself. It should. That is one of the main purposes of an application development platform.

The question is whether the requirement benefits from that freedom. If an organisation genuinely needs a custom interface, unusual logic or a particular application architecture, detailed control is valuable. If the requirement is an inspection process involving allocated work, offline forms, photographs, approvals and a finished report, the ability to redesign every part of the underlying application may be less important.

There is also a practical side to freedom that comparisons rarely mention. When almost anything is possible, every part of the application becomes a decision: how jobs should be structured, how photographs should be stored, how the screens should look, how offline records should synchronise. Each of those decisions takes time, and teams can find themselves debating the design of the application long before anyone in the field is using it. Having more choices is not always the same as making progress. A product with sensible boundaries makes many of those decisions in advance, leaving the organisation free to concentrate on the process itself.

That does not make flexibility a disadvantage. It simply means its value depends on what you are trying to create.

Different skills, different ownership

The people involved and what the organisation owns afterwards follow the same pattern.

A Power Apps project relies more heavily on people who know how to create and manage applications: makers, developers and those who understand data, security and the wider Power Platform. With WorkMobile, the organisation still needs people who understand the operational process, but more of the application framework is supplied within the product, with WorkMobile supporting configuration and implementation.

Once the application is live, the organisation using Power Apps owns what it has built, including the responsibility for supporting and changing it. With WorkMobile, the organisation owns its process and configuration while we maintain the core product underneath. As I covered in the previous article, two applications that look similar to the user can leave very different responsibilities behind.

Microsoft does not have to disappear from the picture

There is another assumption I occasionally come across when comparing a Microsoft platform with a product such as WorkMobile: that choosing the latter must mean moving away from Microsoft.

That is not necessarily the case.

Power Apps is a native part of Microsoft Power Platform and works very closely with Dataverse, Dynamics 365 and other Microsoft services.

WorkMobile can sit alongside that environment. Power Automate can pass activity between WorkMobile and Microsoft services, while WorkMobile data can also be made available through Microsoft SQL Server for reporting, integration or analysis elsewhere in the business.

The question therefore does not always have to be “Microsoft or WorkMobile?”. An organisation may use Microsoft extensively while choosing a specialist operational platform for a particular type of field process. I will come back to that later in this series, because there are situations where using the two together makes more sense than asking one platform to do everything.

So what should a comparison actually tell you?

I still think comparison tables are useful. They force you to put the products next to each other and make the differences visible.

What I would not use them for is counting ticks.

Power Apps offers a much broader range of possibilities. An organisation can decide how almost every part of the application should work and can extend it well beyond the boundaries of a particular operational product.

WorkMobile is deliberately more focused. It is designed around a particular family of field and operational problems. Where the requirement fits that structure, many of the common components are already there.

So if I were comparing the two, I would not ask which platform has the longest list of features. I would ask what the organisation has to create, configure and continue to look after to get the process it actually needs.

A feature list tells you what is possible.

It does not always tell you what you are signing up to.

This article is part of a series exploring the themes in WorkMobile’s white paper, Power Apps Can Build Almost Anything. But Should It?

Read the full white paper →