Mobile for short, clear decisions
The app shows the required tenant context, request and decision-relevant information. It supports simple approvals. This does not include complex rule redesigns or broad administrative write access.
Complex changes remain in the web cockpit
Rule dependencies, includes and excludes, tunnels, extensive policy changes and deeper analysis require sufficient space and context. These workflows remain in the web interface. Mobile should make decisions easier, not squeeze full administration onto a small screen.
- Review tenant and request.
- Read the source, status and decision-relevant context.
- Decide a simple approval or leave it open for further review.
- Follow the result and read-back in the task.
iOS and Android
The native app is distributed through the Apple App Store and Google Play. Roles and tenant isolation apply just as they do on the web. An MSP can see only the tenants it actually manages.
The approval view combines requester, destination, reason, tenant, validity and current status. Administrators do not have to assemble these details from several interfaces. After the decision, the result remains synchronised with the task in the web cockpit, so mobile and desktop work show the same processing state.
What makes a mobile decision complete
An approve or reject button is not enough. Before a decision, the app must at least show the tenant and request, who initiated the case, the stated reason and the current authoritative status. Depending on the workflow, source, data age, coverage and intended target state can also be relevant.
The presentation is deliberately reduced to the decision need. Detail remains available without forcing the user through a complete administration interface. If the context is insufficient for a reliable decision, the task stays open and can continue in the web cockpit.
Typical simple approvals
Mobile is suitable for clearly bounded requests such as one website or application approval when tenant policy and role permit that path. The request carries the business reason and available risk or policy context. The app does not turn several unrelated changes into one bulk decision.
Even a simple task remains tenant-bound. For an MSP, the managed customer must therefore be unmistakable before every decision. Switching tenants must never carry a selected decision into another customer context.
From decision to confirmed effect
The mobile decision is one step in the overall workflow. If it triggers a change in the Zscaler target system, the responsible adapter executes the controlled write. CentaurNexus confirms success only after the effect exists and read-back shows the expected state.
The administrator can then follow status in the app. Decided and effective remain separate. If states differ, the app links to the actionable task instead of hiding a technical failure behind a successful decision.
Why complex policy work needs more space
A rule can contain includes, excludes, order, tunnels, groups, time conditions and other dependencies. These relationships must be visible together before a change. A small display is not the right place for a deep redesign with many comparison points.
The web cockpit provides the larger workspace and complete review paths. The app makes the part that is sensible and bounded on mobile easier. This division reduces operating mistakes and keeps the mobile interface understandable.
Security and session boundaries
The app uses the same role and tenant model as the web interface. Mobile sign-in does not expand permissions. Session state, revoked access and assignment to the authenticated operator must be valid before a decision.
Device protection and store distribution are aligned with the customer operating model. MDM-assisted ZCC rollout and the first concrete MDM connector remain separate dependent decisions and are not implied by the availability of the admin app.
Notifications without decision pressure
Push notifications can highlight a new or overdue approval. The notification itself should contain only the necessary context. The decision follows after the protected task has been opened.
The app must not manufacture urgency. Priority, deadline and impact come from the task. If deeper review is required, choosing to continue later in the web cockpit is a correct outcome rather than a mobile workflow failure.
Behaviour on an unreliable connection
A mobile interface is often used across changing networks. If current state cannot be loaded reliably, the app must not present stale information as a decision basis. Data age and connection state need to remain visible.
A decision is accepted only after confirmed transmission. Offline batches of cached approvals would not fit this model. The user receives a clear response and can reopen the task when connectivity returns.
Measure mobile use meaningfully
Installation count alone does not demonstrate value. Relevant measures include completed simple approvals, tasks stopped because context was insufficient, time to decision, correct tenant assignment and cases deliberately continued on the web.
Continuing on the web is not automatically negative. For complex tasks, it demonstrates that the intended boundary works. Measures are evaluated by tenant and rollout phase rather than published as a universal performance claim.
A typical mobile working day
An administrator receives a notification about one application request while away from a desk. She opens the protected task, reviews tenant, requester, reason and available context, and makes the simple decision. Technical execution then continues through the controlled backend independently of the mobile connection.
A later policy request contains several dependencies. The app shows that full review is required on the web. The task remains open, keeps its priority and can continue on a notebook without another search.
Accessibility and readability on small displays
Decision reason, tenant and primary action must remain understandable with enlarged text and a screen reader. Colour alone cannot carry a risk or error state. Focus order, touch targets and confirmation dialogs are reviewed separately on iOS and Android, including landscape orientation and zoom.
Acceptance before store distribution
- Define the list of simple mobile approvals.
- Test roles and tenant switching for internal teams and MSPs.
- Review decision context on small and large devices.
- Accept read-back, error states and revoked sessions.
- Review push content and lock-screen privacy.
- Verify Apple App Store and Google Play packaging.
The native app makes short administrative decisions easier. It remains part of the same governance as the web cockpit and keeps complex work where the required context can be displayed completely.
Frequently asked questions
Which systems does the app support?
The native app is provided for iOS and Android through their respective stores.
Can I redesign complex rules on mobile?
No. The app supports simple approvals. Complex rule changes remain in the web cockpit.
Do the same roles apply on mobile?
Yes. Tenant context, roles and approval policy also apply in the app.
Sources and further information
See the workflow in context
Choose the relevant role in the demo launcher. The demo uses prepared sample data.
Open demo launcher