Before sharing: inspect data, secrets and ownership
Search the source and built assets for hard-coded records, access keys and private endpoints. A browser receives the JavaScript and data served to it, even if a screen hides a panel. Remove company information that was copied into a fixture. Move privileged operations behind an appropriate server boundary and rotate any secret that has already been exposed. Deleting a value from the latest commit does not revoke the old value.
Name an App Owner and support contact who can answer a colleague's next question. Preserve the source and the build settings so another maintainer can reproduce the release. Check whether the app saves only to local browser storage or to a shared service. A local example can demonstrate a review interaction without providing a multi-user approval system; add the missing production behaviour before using it for business decisions.
Agree what data the app needs. An employee's access to a company system is not an automatic grant for every app the employee builds. For SpringRoll Connect, review the intended application environment, fields or native operations, row restrictions, limits and expiry. Test what the screen does when access is missing rather than presenting an empty result as an authoritative answer.
Step 1: verify the deployed release
Wait for the actual deployment to reach READY, then open the working app outside the development server. Complete its core task with a known fictional record and compare the result with the expected outcome. Inspect a narrow screen, an empty state and a failed request. Keep the release, deployment and environment together in the verification record.
If the latest attempt failed, fix its build or configuration error before sharing that attempt. The current working version and the latest deployment are different facts. A coding agent reporting that it submitted a request is not evidence that the app is live. Keep the owner involved when the intended behaviour changes during the fix, rather than silently handing over a different workflow.
Step 2: choose the audience and copy the app link
Use the app's Access controls to select the intended audience and verify the audience shown beside Copy app link. Share the SpringRoll launch link, not a localhost address or an arbitrary build output URL. Colleagues should be able to find the app through their App Portal when it is available to them. Include a sentence describing the task and the support contact when you send the link.
Choose the smallest audience that matches the work. Giving an entire workspace access because two reviewers need a preview broadens the handoff unnecessarily. Review group membership and role choices with the person responsible for access. If another employee requests access, use the configured request and approval path rather than borrowing an allowed colleague's identity.
Step 3: distinguish Test from Production
A staged app uses different environments for review and daily work. Share Test for the review task and Production for the approved everyday task, and label the link accordingly. Check that the test environment uses suitable data and that a reviewer knows which release they are assessing. Do not infer that a link is a preview solely because the app was created recently.
Direct to Production is the default SpringRoll workflow. A Tenant Admin can configure Staged when releases must pass Development, UAT and Production review. That release workflow is separate from who may launch an environment and from the business decisions made inside the app. A purchase request app still needs its own server-side rule for who may approve a purchase.
Step 4: test an allowed and a denied identity
Use two distinct accounts. The intended colleague should discover and launch the correct app environment, perform the permitted task and see only the information needed for that task. The account outside the audience should fail to launch through SpringRoll and receive the appropriate access-request experience. Record the expected and observed result for both identities without copying credentials into the record.
Continue the test inside the running application. Try a business operation the user should not perform, including a direct request to its server endpoint where applicable. Hiding an approval button in the browser is not server-side enforcement. For connected data, verify denied and revoked access as well as a successful query. These checks answer different questions from whether the portal link opens.
Check the direct provider hostname separately
Follow the security guide's origin-access review with a fresh session and a denied identity. Check every relevant deployment URL, not only the custom domain sent to colleagues. Record which control protects each route and who maintains its configuration.
Vercel documents protection methods and scopes for deployment URLs. Cloudflare Access documents policies for self-hosted applications and origin validation. Reviewed 31 October 2026: inspect the current configuration and entitlements for your project, then record which URLs the selected policy covers.
Keep the link useful after the first handoff
Keep the app's description, owner and support route current as the team starts using it. Recheck the audience when a group changes purpose, an employee leaves or the application begins exposing a more sensitive dataset. Review environment-specific data grants independently. A bookmark to a working app is convenient, but it should not become the only record of who maintains the tool.
If the app is no longer appropriate, use the governed suspend or retirement process and review access at the provider and data-source boundaries too. Revoking a portal audience is useful for future portal launches; it is not proof that an old origin link, external session or copied dataset has disappeared. Record what was revoked, what remains and who will verify the final state.
Frequently asked questions
Is a Vercel preview private?
Check its actual Deployment Protection method and scope. A preview URL's name or unpredictability is not proof of access control. Test the relevant URL as an unknown visitor and a denied identity.
How do I revoke access?
Update the portal audience or membership through the appropriate workflow, review the application's data grants, and separately revoke any origin or application access. Verify the result with the affected identity.
Does sharing an introduction page change the running app's audience?
No. A public app introduction and permission to launch the running environment are separate decisions. Verify the running app's audience and direct access path.