See the result first. Decide what happens next.
The review workspace is designed for merchants and technical reviewers. It leads with the proposed storefront, explains the change and keeps production authority explicit.
Preview, approval and deployment are separate controls so merchants can understand the result before anything reaches production.
Review the proposed implementation in staging.
Use Desktop, Tablet and Mobile controls to inspect the relevant storefront area. Refresh the preview after a revision and open staging in a separate tab when you need normal browsing behavior.
Open the current live storefront beside the proposal.
The live link provides the current production reference while staging shows the proposed state. Verify the intended change without confusing approval with publication.
Read what changed, where, why and with what risk.
The merchant summary identifies the expected behavior, affected file count, staging environment and risk level. Technical details remain available for anyone who needs to inspect the code.
Use automated checks as evidence, not as a substitute for merchant review.
QA reports whether the configured checks passed. Confirm the actual customer-facing behavior and use Request changes when the proposal is technically valid but does not meet the business expectation.
Approval confirms the proposal but does not publish it.
Approve implementation only after the preview matches the request. The approved status records the decision and enables the separate deployment action.
Deploy to live as the final consequential action.
Deployment writes the approved changes to the live theme and customers may see them immediately. QA overrides require an explicit reason and should remain exceptional.
Related TaskerArmy pages
Direct answers before installation
Does Approve implementation change the live store?
No. It records approval. Deploy to live is a separate action.
What should I check in the preview?
Confirm the intended behavior, mobile layout, navigation, purchase actions and that no important content is obscured or broken.
What should I do when QA fails?
Request correction and review the new staging result. Do not use a QA override as the ordinary path.
Can another team member approve or deploy?
Permissions depend on the member role and delegated authority. Deployment should remain limited to the owner or an explicitly authorized administrator.
Connect the store. Start with evidence.
Run the connected-store audit, review prioritized findings and decide which bounded engineering job should move to staging first.