AI-built app handoff checklist for IT teams

Record an accountable App Owner, department and support contact. Write down the task the app solves and the person who will verify it. Keep a current source bundle or repository so the next change is repeatable.

In the fictional Northwind workspace, Cleo owns Sales Order Dashboard for Sales Operations. Its support contact is #sales-ops on Slack. Its restricted audience includes Cleo and Eli.

• Inspect an example app record →

Use Direct to Production for the direct release path, or configure Staged for Development, UAT and Production review. Record which environment is being tested, the release ID and the build result. Run the app's main task after READY.

• Set up the workflow →

Choose the audience in Access, then use Copy app link. Test the same link with two accounts.

• Intended colleague: sees the app in the portal and launches the selected environment.
• Colleague outside the audience: launch is denied. The page directs them to contact the person who shared the link; an app manager can review the audience.
• Direct provider URL: verify application or provider authentication independently. Portal launch rules control the SpringRoll path, so record the result for the origin URL too.
• Save the release, environment, test identities, expected result and observed result in the handoff. Never include credentials.

A data-product gateway grant controls selected fields and query rules. A native connector grant authorizes selected APIs and follows the source account's permissions. Choose the route for the app, review its environment-specific grant and verify the result with sample data first.

Publish the app's description and owner, share its SpringRoll link and show the team one complete task. Our team helps with deployment, data connections and the launch handoff.

• Try example internal apps →
• Plan your team launch with us →

An app can outlive the employee who first built it. Identify the replacement owner before an absence or role change, review the source and deployment records together, and make sure support contact details point to someone who remains accountable. Transfer ownership through the governed workflow rather than sharing the builder's login.

Review launch audiences, application identities and environment-specific data grants when responsibilities change. A colleague's personal access to a source system is not an application grant. Verify the running app after the transfer, record the next maintenance task and give the incoming owner a way to suspend the app if its purpose or data access is no longer appropriate.

After the build is READY, open the app’s Access controls. Select the colleagues or group allowed to use it. Use Copy app link for the environment they need. Colleagues sign in when they open the link, and SpringRoll checks their launch access.

If your colleague hasn’t joined the workspace, ask an administrator to invite them. If they’re already a member but the app won’t open, ask them to contact the person who shared the link. An app manager can check whether that colleague belongs in the audience and update access for them.

• With an allowed account, open the app from the portal and finish the team's task. With a different account outside the audience, verify that SpringRoll denies launch.
• Open the direct provider hostname separately. Verify its authentication and test the app's server-side permissions for the same two people.
• Send the verified link with the owner's name and support contact. Check the app's data grants separately whenever the audience or task changes.
• For a staged release, check the recorded decision. In the Northwind example, Ada Okafor approved Legacy Shift Planner v0.1.0 for Production on 31 October 2026. That decision released the version; the app owner still chooses who can launch it.

• Test the direct provider URL →
• App Portal permissions →
• Read Northwind’s release decision →