remoteEaze

Access, installation, and security

How to access, install, and protect Workbench.

Workbench is available only to a user whose Role is marked Field Agent Role. Dashboard access is independent: enabling Dashboard Access allows the same Agent Role to use both surfaces, but the user's default landing page remains Workbench.

First access

  1. Connect the device and sign in as the intended Agent.
  2. Open Workbench. remoteEaze confirms that the user may use Workbench and prepares the permissions and Branch access that apply to that user.
  3. When prompted, protect local Workbench data with a passphrase of at least eight characters. A supported native installation may use device credentials or biometrics.
  4. Use the profile menu's install option when the browser supports installing the Progressive Web App.

Protect the device

Workbench stores Drafts, submitted work waiting to synchronize, and prepared business data on the device. That information is protected for the enrolled user. Another user or company cannot silently open it.

If Workbench reports that the user, installation, or local protection no longer matches, follow the recovery message. A local reset removes work that has not synchronized, so review the warning carefully before continuing.

Synchronize all work before logging out, changing the device user, or resetting Workbench.

One-day offline access

The standard offline access period is one day from the most recent successful online validation. After it expires, reconnect and sign in before continuing. A deployment can use a different period within the platform's supported range.

While connected, and again when queued work reaches the server, remoteEaze rechecks working hours, weekend and holiday restrictions, user and Role status, permissions, and data-access scope. Work captured offline is therefore not a way to bypass a later access change.

Module navigation follows the current local authorization snapshot. If access is removed, Workbench hides the ordinary server-backed module entry but keeps a recovery path visible while that user still owns a local Draft or unsynchronized queue item for the module.

For the technical security model, see How offline access is protected.

On this page