remoteEaze

How offline access is protected

The security checks behind Workbench offline access, explained in operational terms.

Workbench permits offline work only after a successful online sign-in. During that sign-in, remoteEaze records who may use the device, which company and Branch apply, and which permissions and data-access rules are current.

The checks Workbench keeps locally

Workbench protects three related things:

  • Access confirmation identifies the user, company, Agent context, and the time at which offline access expires.
  • Permission snapshot records the modules and actions the user was allowed to use at the last online validation.
  • Prepared data contains the scoped Customers, Accounts, Products, policies, and configuration needed by each enabled journey.

These checks are tied to the enrolled user and installation. They are not transferable to another user or company.

Validity and refresh

The standard offline validity period is 24 hours. It starts again only after a successful online validation. A quick online check that finds no data changes does not silently extend an already prepared data set forever.

When the period expires, the device must reconnect. Workbench preserves local Drafts, but blocks new protected work until access and prepared data are valid again.

Local unlock and recovery

The passphrase, device credential, or biometric unlock protects the locally stored information. It does not grant new server permissions. If the local key is locked, unlock it using the method configured during enrollment.

If Workbench detects a different user, company, or installation, it stops and offers recovery. Review any unsynchronized work before choosing a reset because a reset removes that device-only data.

What happens during synchronization

Offline permission is provisional. When the device reconnects, the server validates the submitted action again using the current user status, Role, permissions, data-access scope, business configuration, and record state. A captured item can therefore be rejected after a permission or configuration change. Correct the cause, refresh the prepared data, then use the recovery steps shown for that item.

On this page