What Is a PWA (Progressive Web App)? Its Use in B2B Field Operations and Customer Portals

A PWA (Progressive Web App) is a web application approach that uses web technologies while providing an experience similar to a mobile application. Its ability to run in a browser, be installed on supported devices and, with the right architecture, maintain selected functions without a connection makes a PWA a valuable option for B2B field operations and dealer and customer portals.

However, a PWA is not simply an existing website with an “add to home screen” option. Its real value comes from designing user roles, offline-capable processes, data synchronisation, ERP connections and security rules together. The decision should therefore be based on the conditions of the business process before the technology label itself.

What is a PWA, and how does it differ from a conventional web application?

According to MDN’s explanation of PWAs, progressive web applications can be developed with web platform technologies while offering an experience similar to platform-specific applications. A web app manifest defines installation details such as the application’s name, icon and display mode. A service worker can be used to provide capabilities such as offline access and background operations.

A conventional web application usually depends on a network connection and an open browser tab. With the PWA approach, the application shell and selected content can be cached, suitable transactions can be stored temporarily on the device and transferred to the server when the connection returns. These capabilities do not appear automatically, however. The system must also define which data will be stored, for how long and how users will be informed when outdated data is displayed.

A PWA does not have to be a single-page application. An existing or new web application can adopt supported features progressively. Core functions can therefore continue to work in browsers that do not support advanced web APIs, while compatible devices can offer additional capabilities such as installation, caching and offline transactions.

What does a PWA offer for B2B field operations?

Field sales representatives, technical service teams and inspection personnel do not always work with a stable connection. Factories, warehouses, rural areas and travel can all create environments where mobile connectivity is slow or unavailable. If every screen must wait for an immediate server response, visit records, draft orders and service forms may be left incomplete.

With a PWA, recently used customer lists, tasks, limited product information and form templates can be stored on the device in a controlled manner. A user can create a visit note, attach a photograph or form and save the transaction to a local queue. The queued records are sent to the server when the connection returns. Depending on the project scope, these requirements should be evaluated together as part of the web and mobile software approach.

The critical distinction is between “opening a screen offline” and “completing a business process offline.” Displaying a product catalogue is relatively straightforward, while stock reservations, current price validation and credit-limit checks may require central data. The system should not present these transactions as final results. It should show clear states such as draft, awaiting submission, validation required or rejected.

Use cases in customer and dealer portals

Users of a B2B customer portal may want to place orders, track shipments, download documents, open support requests or view account information. An installable PWA can reduce friction for repeat use by allowing users to open a frequently used portal from an application icon. Adapting a single codebase to different screen sizes can also simplify deployment and version management.

Tasks such as quick ordering, stock enquiries, draft quotations and field visits are strong PWA candidates for dealers. However, the freshness of data such as real-time stock, customer-specific prices, discount authorisations and financial balances must be clearly stated. For example, the interface should show when a price was last verified and perform another server-side check before confirming an order.

The statuses a customer sees from order placement through shipment are not limited to the PWA interface. The source system, partial shipments, document access and exception management must be considered together. The portal interface and integration layer should be planned as parts of the same workflow.

How should an offline operating model be designed?

Not every function needs to work offline

The first step is to classify transactions according to their connectivity requirements. A read-only customer summary or form template can be downloaded in advance. Visit notes and inventory counts can be created locally and queued. Real-time credit checks, payments and final reservations may require online validation. This classification prevents unnecessary data storage and avoids giving users a false sense of certainty.

The web.dev service worker guide explains that a service worker can act as an intermediary handling network requests between an application and its servers. The same caching strategy should not be applied to every resource, however. Application files, product images, reference data and transaction responses require different freshness rules.

The transaction queue should be visible to users

Every record created offline should be assigned a unique transaction ID. Users should be able to see which transactions are waiting on the device, which have been sent and which require intervention. The interface must clearly state whether a “Saved” message refers to a local record or acceptance by the ERP system.

• Display the number of pending transactions and the last synchronisation time.
• Provide an understandable error reason and a retry option for failed records.
• Ensure that resubmitting the same transaction does not create duplicate server records.
• Define how local data will be cleared when the user signs out.

Define the conflict policy in advance

While a record is being edited offline, another user may change it in the central system. A “last write wins” approach can cause data loss in ordering and service processes. Conflicts should be detected using server version numbers, timestamps and field-level comparisons. Cases that cannot be merged automatically should be referred to the user or operations team.

ERP and enterprise system integration

A PWA should not connect directly to an ERP database. A secure API or integration layer should sit between the portal and ERP system to handle authentication, authorisation, data transformation and error management. This prevents the ERP’s internal data model from being exposed to the client and allows the portal to receive only the required fields through controlled contracts.

Reference data such as products, accounts, prices and stock can be transferred from the ERP system to the portal, while orders, service forms and visit outcomes can be sent in the opposite direction. A technically successful HTTP response does not mean the ERP system has accepted a transaction under its business rules. The portal should manage statuses such as received, under validation, accepted, partially processed and rejected separately.

The integration design should answer the following questions:

• Which system is the source of truth for each data field?
• How long are price, stock and limit data considered valid?
• Which errors trigger an automatic retry?
• Which unique key prevents duplicate transactions?
• What status does the user see when the ERP system is temporarily unavailable?
• Who monitors transaction history and integration errors?

Why should user roles and workflows be central to the project?

Field representatives, dealer users, customer purchasing officers, managers and support teams do not have the same permissions in a B2B portal. Accessible customers, price levels, document types, approval limits and transaction permissions should be defined by role. Permission controls should not be limited to hiding buttons in the interface; they must be enforced server-side for every API request.

Offline authorisation also requires separate consideration. Role and scope information stored on a device should not remain valid indefinitely. Rules should be defined for sessions, device trust and the last permission refresh. Old data must not remain accessible on the device of a user who has left the organisation or whose permissions have changed.

• Customer and task lists can be read from the cache, but the last update time should be shown to the user.
• Visit notes and forms can be stored in a local queue, with a unique transaction ID assigned to every record.
• Price and stock information can be presented from a time-limited cache, but its freshness should be clearly stated.
• Order confirmation should require online server approval, and ERP acceptance should be tracked separately.
• Access to sensitive financial information should be restricted, and unnecessary data should not be retained on the device.

How should PWA security be handled?

PWAs are web applications that require HTTPS, secure session management, input validation, access control and regular security testing. Offline capabilities add the risk of data being stored on the device. The OWASP browser storage testing guide recommends checking whether sensitive data is stored unnecessarily on the client side. Authentication tokens and business data can increase the impact of client-side attacks.

The offline dataset should therefore follow the principle of storing only what is necessary. Sensitive fields should either not be downloaded or should be restricted according to the business need. Requirements should be defined for session duration, reauthentication, lost devices, data clearing on sign-out and cache versions. XSS protections, a content security policy, dependency updates and role-based API testing should also be included in the development lifecycle.

Performance, testing and sustainable management

The PWA label alone does not guarantee a fast experience. Large JavaScript bundles, unoptimised images and excessive data downloads can reduce performance, particularly on lower-powered field devices. Initial launch, subsequent launches, slow connections and offline launch should be measured separately. Only the necessary screens and data should be loaded, caches should be versioned and outdated resources should be removed.

The test matrix should reflect real operating conditions. In addition to different screen sizes and browsers, tests should cover connectivity loss during a transaction, application closure, full device storage, session expiry and ERP unavailability. It should also be verified that pending local records are preserved when a new version is released and that the data schema can be upgraded safely.

After launch, teams should monitor the synchronisation success rate, age of pending queue items, API error rates, launch time and version distribution. Allowing the support team to trace an issue through its transaction ID without requesting sensitive data from the user makes ongoing management easier.

PWA or native mobile application?

A PWA is a strong candidate for projects where rapid browser access, a single web codebase, centralised updates and ease of installation are priorities. Forms, draft orders, visit records, document access and controlled offline queues can be well suited to this model.

A native or hybrid mobile application may be more appropriate when extensive hardware access, long-running background processes, operating-system-specific features or highly predictable platform behaviour are required. Browser and operating system support is not identical across every device. The decision should be based on the target device inventory, required APIs, security policy and total lifecycle cost. Similar application types and use cases can be reviewed on Kumsal Agency’s mobile application project page.

Recommended roadmap for a B2B PWA project

• Research users, field conditions and critical tasks.
• Classify online, offline and read-only functions.
• Define roles, permissions, approvals and exception flows.
• Design local data, synchronisation, conflict and retry policies.
• Prepare API contracts for the ERP platform and other enterprise systems.
• Test connectivity loss, security and performance on real devices.
• Assign responsibilities for monitoring, support, updates and data removal.

Evaluate PWA suitability through the business process

A successful B2B PWA is more than a mobile-looking portal. It clearly manages which tasks users can continue when connectivity is lost, when transactions become final, how current ERP data is and which information can be stored safely on the device.

Kumsal Agency approaches custom web software as a whole, covering user roles, workflows, mobile-friendly experiences, ERP integration, data security, performance and sustainable management. To assess PWA suitability, the offline operating model and integration requirements for your B2B field or customer portal, you can contact Kumsal Agency.