--- lastModified: 2026-10-12 type: feature title: "Website Collaboration Tool for Storefront Teams" description: "Use Runner AI as a website collaboration tool to invite teammates, check workspace access, and review storefront changes together before choosing to publish." category: ai-websites h1: "A Website Collaboration Tool for Your Store Team" keyword: "website collaboration tool" legacyKind: structured --- A **website collaboration tool** helps a store team work from the same project instead of passing around disconnected drafts. Runner AI provides workspace membership, email invitations, and storefront previews. Start with the intended workspace, an eligible team plan, and the teammate's email. The result is shared workspace access and a storefront your team can inspect, not an automatic approval process or a promise of simultaneous editing. ## Set up your website collaboration tool around the right workspace Before inviting anyone, open the store-name menu and go to **Workspace Settings**, then **Members**. Confirm the workspace name rather than relying on whichever store was open last. The Members page combines active members and pending invitations, so you can check whether your teammate already has access or is still waiting to join. Search by name or email before sending another invitation. Member management depends on both your role and the workspace plan. An owner or admin can send invitations when the plan supports team seats and capacity is available. Follow the plan gate shown in Runner rather than assuming that every account includes collaboration. Seat availability considers pending invitations as well as existing members; an unanswered invitation can therefore prevent another invite even when the active-member count looks low. Decide what the teammate needs to do before granting access. A colleague checking product copy needs a clear review brief, not a request to change every part of the store. Workspace membership concerns access to workspace projects. Do not describe an invitation as a link that exposes only one selected screenshot or creates a separate customer-facing store. ## Invite a teammate and confirm that they joined Select **Invite people** when the control is available, enter the intended email address, and choose **Send invite**. Check the resulting notification and the pending row. Sending the email is the start of onboarding, not proof that the person can already open your store. The invitation form does not include a role selector; review the member's role after they join instead of expecting to choose it while entering the email. Your teammate opens the invitation link, signs in with the invited address, confirms the workspace, and chooses **Join**. A wrong-account state means the person needs to sign in with the address that received the invitation. A full-workspace state needs the inviter to resolve capacity. Expired or cancelled invitations need a new invitation from an authorized owner or admin, not repeated attempts with a link that no longer works. Return to Members and confirm that the row is active. Then ask the teammate to open the intended workspace and store. Keep these two checks separate: a successful membership change establishes access, while opening the project establishes that the person found the right work. **Invite Friends** is a referral flow, not a replacement for a workspace invitation. ## Give storefront review a route, a task, and an expected result After access is confirmed, choose the storefront page and customer task the team should review. A useful handoff names the route, current version when known, device frame, approved content, and expected result. For a collection-page revision, ask the reviewer to find a product through the collection link and check the introduction against approved copy. That is more concrete than asking whether the whole store looks finished. Use the [website preview tool](/website-preview-tool) to inspect the storefront and follow its routes. Both people should identify the same review target; an older task's preview and the current storefront can show different results. Check the requested visible change instead of treating a completed chat response as proof that the preview contains it. Preview review does not publish the store. If the reviewer finds a problem, send Runner a bounded correction request with the starting state, action, expected result, and observed result. The [AI website editor](/ai-website-editor) covers those edits. Agree within your team who will request the correction and who will retest it. This is a suggested working practice, not a claim that Runner locks a page for one editor, assigns review tasks, or automatically merges conflicting requests. ## Keep access decisions separate from launch decisions Review roles on the Members page when your permissions allow it. Owner, admin, and member roles have different management rights; a visible control does not override the role hierarchy. Confirm the displayed role after a change rather than assuming that opening a menu completed the update. Give administrative access only when the person's responsibilities call for it. Clean up invitations deliberately. Cancelling a pending invitation invalidates it without another confirmation. Removing a member or leaving the workspace opens a confirmation about losing access to workspace projects. Check the person and workspace before confirming, and cancel if access should remain. Do not remove a teammate merely to retry a failed invitation without first understanding the state. When the team agrees that the storefront change is ready, publication is still a separate action. The [publishing a website](/publishing-a-website) workflow covers checking the public result. Shared access and a passing visual review do not prove payment readiness, inventory accuracy, shipping eligibility, or checkout completion. Test the customer journey with the correct connected services and authorization before inviting shoppers to order. [Explore all Runner AI features](/) ## Website collaboration tool FAQ ### Can anyone invite a teammate to a Runner workspace? No. Invitations require an eligible workspace plan, available seat capacity, and owner or admin permissions. Pending invitations count toward the invitation capacity check. Open Workspace Settings and Members to review the current state. If Invite people is absent or disabled, resolve the plan, role, or capacity issue rather than sharing your own sign-in credentials. ### Does an invitation make the teammate active immediately? No. A sent invitation appears as pending until the teammate accepts it using the invited account. They must confirm the intended workspace and choose Join. Check that the Members row becomes active, then confirm that they can find the intended store. A sent-email notification alone does not establish that onboarding is complete. ### Is Runner a simultaneous website editor or approval system? This website collaboration tool supports workspace access and a reviewable storefront workflow. It does not establish a real-time co-editing session, page locking, or automated approval routing. Your team should agree who requests each change and who checks the result. Keep the route and version in the handoff so feedback refers to the same work. ### Does a teammate reviewing the preview publish the store? No. Inspecting a preview is separate from publishing a website. After a correction, repeat the affected customer task and verify the intended version. Make the launch decision separately and inspect the public store afterward. Workspace membership, a finished task, and a visually correct page are not substitutes for checking the purchase flow and its connected services.