Apps now brings the work that needs you above your app list. Approval briefs, data requests and release records explain what changes, what has been checked and who can take the next step, with the same facts on desktop and phone.
The work that needs you, above your apps
Everyone starts on Apps. Needs you shows the requests and app actions you can act on, while Your requests keeps track of work waiting on someone else. App cards and Overview name the next person and action. Reported problems and planned withdrawals appear before you open an affected app, and app managers can resolve reports with a recorded outcome.
Why we built it: People should be able to find their next useful action without checking several registers or mistaking somebody else's queue for their own. Keeping problems beside the app also makes them easier to report and follow through.
Approval briefs with current evidence
Each brief brings together the proposed change, requester, current app risk, warnings and named reviewers. Release reviews distinguish a UAT deployment from business sign-off. Data reviews name the requested fields and their sensitivity, and audience changes show who would be added or removed. No decision is selected in advance; rejection and requests for changes require a note.
Why we built it: A decision needs more than a status or a technical identifier. Reviewers can now compare the request with the recorded evidence and explain their choice, while requesters can see who still needs to act.
Release records that separate approval from going live
An approved release names who can deploy it and continues to say when it is not live yet. Apps, Overview and environment pages share the same next step. Deployment records distinguish queued, running and completed work, and keep the hosting candidates, limits and cost information available. Audit summaries reduce repeated bookkeeping while preserving the underlying events and uncertain outcomes.
Why we built it: Approval is one step in a release, not evidence that users can already open it. Clear handoffs and recorded outcomes help builders and owners know when to act, when to wait and what to investigate.
Data access with a clear scope and owner
Data products show their owner, source health and the apps with access alongside exploration and publishing. Access requests explain the chosen fields, purpose, environment and expiry in days. After a request is recorded, the form gives way to its outcome and a link to follow it. Existing requests and partial grants remain visible so another request does not hide what is already waiting or allowed.
Why we built it: An app builder should know what data they are asking for and where the request goes. Owners need the same scope when granting all, granting some or rejecting access, without exposing credentials or relying on technical field names.
Readable records and reachable actions on phones
Approval history, Members and Audit trail use compact rows on narrow screens. The navigation drawer scrolls to account actions and Sign out, while decision forms keep their choices and submit action reachable. Invitations name who invited you, the role and the expiry, and unknown workspace paths keep signed-in members inside their workspace with a way back to Apps.
Why we built it: Following a request or making a decision should remain practical away from a large screen. Consistent names, dates and recovery links help people understand where they are and finish the task they came for.
Also improved
- Recertification tasks, notifications and audit records are saved together, including overdue transitions, so concurrent checks do not create duplicate work.
- Public pages, Connect entry links and starter downloads remain reachable while unknown public addresses return a real not-found response.
- Page titles, named contacts and shared reviewer names are clearer across connected accounts, invitations and approval routing.