Approvals on mobile happen where the record is. There is no separate approvals inbox in the app: the approval panel sits on the record itself, and that one panel carries the whole lifecycle — submitting, the step-by-step timeline, approving and rejecting, reassignment, recall, and the history of past requests. How approval processes themselves are designed — steps, approvers, entry criteria — is web-side configuration, covered in Approval processes.
Prerequisites
- An approval process configured for the record type, and the approval panel present on its mobile layout — both set up by your administrator.
- A connection. Approval decisions post to the server directly; the panel is the one part of a record screen that tells you plainly it is Not available offline rather than working from device data.
- The right relationship to the request for each action: submitting takes access to the record, deciding takes being the pending step's assignee.
Procedure
This procedure deliberately has no web screenshot. The native approval widget is embedded on the mobile record and has its own timeline and action drawers; the web Approvals inbox is a different surface and would imply an inbox that does not exist in the mobile app. Add a visual only when a demo2 mobile record contains the configured approval panel and a safe request state to inspect without acting on it.
Step 1 — Find the panel on the record
Open the exact business record named by the notification or web inbox, verify its identity and current values, and scroll to the approval panel. It shows a submit card for an eligible record with no open request or the live status/timeline. Confirm connectivity and refresh once before concluding a panel is absent; if entry criteria are unmet, it correctly stays quiet.
Step 2 — Submit for approval
Review the record first, tap Submit for Approval, enter remarks that state the decision requested and evidence location, and confirm once. Wait for the panel to switch to timeline view and verify the submission entry, first step and assignee. If nothing changes, check connectivity before tapping again so one request is not mistaken for two attempts.
Step 3 — Read the timeline
Read the timeline from submission downward. For each card verify step name, Pending/Approved/Rejected status, actor, timestamp and comments; open completed entries for details. The single Pending card identifies the current assignee and available action. Compare the record values with what was submitted because a pending approval can lock the record and later changes may require recall.
Step 4 — Approve, reject or reassign
If you are the named assignee, open the pending card, re-check supporting evidence, select Approve, Reject or Re-assign, and enter a durable reason. For reassignment, verify the active user's identity before confirmation. Submit once, wait for server response, and confirm the timeline advances, closes as Rejected, or shows the new assignee exactly as intended.
Step 5 — Recall or revert
Use header actions only after confirming the live request status and explaining why the state must change:
- Recall appears while the request is Pending — it withdraws the request, closing it as Recalled. Use it when the submission was premature or the record needs rework; you can resubmit after.
- Revert appears once a request is Approved, where the process allows it — it walks the approval outcome back, recording Reverted. Like every action here, it takes remarks, and it stays in the history rather than erasing the approval.
Step 6 — Read past requests
Below the live timeline, open Past requests and verify the latest closed request shows decision, actor, status and remark. Drill into the complete trail when resubmitting or auditing a record. Recalls, rejections and reversions remain visible; never infer approval from the record's business status alone when the action history is available.
Expected result
The request has one current state, one visible pending step when action remains, and a complete actor/timestamp/comment trail. Decisions made online immediately update the timeline, while recall, reassign, reject, approve and revert remain preserved in past requests.
Common problems
The panel says "Not available offline". Expected: approval state lives on the server and decisions must land there atomically, so the panel does not work from cached data. Everything else on the record still works offline; come back to the panel when you have a connection.
You can see the request but not act on it. The pending step names its assignee — if that is not you, you get the read-only view by design. If the assigned person is unavailable, someone with the step currently assigned can reassign it; otherwise the process's configuration (or an administrator acting on the web) is the path.
There is no panel on a record you expect to approve. Either the record type has no approval process, the record does not meet the process's entry criteria, or the panel is not on this mobile layout. All three are administrator-side; nothing on the device switches it on.
Common questions
Is there an approvals inbox on the mobile app?
No — and it is worth being precise, because the web has richer approval surfaces. On mobile you act on a request from the record it belongs to. Push notifications, where your organization has them enabled for workflow actions, are what bring a waiting approval to your attention; the notification's subject tells you which record to open.
Can I approve or reject while offline?
No. A decision changes the request's state for everyone — approver, submitter, the next step — and queueing it on a device would mean two sources of truth about whether something is approved. The panel therefore requires a connection and says so, rather than pretending.
What is the difference between Recall and Revert?
Direction and timing. Recall is the submitter's exit while the request is still pending — nothing was decided, the request is simply withdrawn. Revert applies after approval, walking the outcome back with a recorded action. Both leave the full trail in past requests.
Do my remarks go anywhere?
Yes — every action takes optional remarks, and they are stored on the request's action trail, visible in the timeline and in past-request details to anyone who can see the record. Treat them as the durable explanation of the decision, because that is exactly how the next reader will use them.