Operate protected Shopify workflows.

Obsidian Guard is in private beta. Access is provisioned with the team before a store is treated as protected.

1. 1. Request access

   Share the Shopify store and risky actions you want to control. The team confirms beta fit and the supported boundary.

2. 2. Connect Shopify

   Complete the Shopify install and identity handoff. The app requests only the scopes needed for the enabled protection set.

3. 3. Verify readiness

   In Overview and Protection, resolve any reconnect, permission, owner-email, protected-refund-rule, or approver-readiness item.

4. 4. Test Refund Guard

   Use a non-production test order when available. Submit through the protected refund action, review the request, and confirm the outcome in Activity.

5. 5. Invite approvers

   Open Approvers, invite the people responsible for refund decisions, and confirm they can access the review path.

6. 6. Configure notifications

   Choose primary and secondary channels in notification preferences and send available test notifications before relying on them.

Protected request

The record created for a supported risky action, including context, assigned reviewers, decisions, and downstream outcome.

Approver

A person assigned to decide a protected request. Approval authority is separate from the ability to submit a request.

Approval group

A Control Guard policy structure that assigns reviewers and enforces group or separation-of-duties requirements.

Bypass

An exposed Shopify action that happened outside the protected Obsidian Guard path. Visibility depends on the event data Shopify provides.

Manual follow-up required

Obsidian Guard could not safely complete or confirm the downstream action. A merchant must inspect Shopify and resolve the operation.

Activity history

The operational record of requests, decisions, detected events, execution outcomes, failures, and acknowledgements available to the workspace.

What this protects

Refunds submitted through the Obsidian Guard Shopify protected action path.

When it triggers

A supported refund request matches the configured rule or threshold. Refund Guard Preview uses the recommended default settings; paid Refund Guard can configure routine controls.

What the requester sees

A request state showing that approval is pending, plus the order/refund context available under the store's Shopify permissions.

What the approver sees

The request, amount and reason context, requester/source evidence, and Approve or Reject decision controls when assigned.

After approval

Obsidian Guard attempts the refund through Shopify when the store has the required permissions and supported order data.

After rejection

The request closes as rejected. Obsidian Guard does not execute the protected refund.

If execution fails

The request records the execution failure and can show manual follow-up required. Verify Shopify state before retrying or refunding natively.

Activity history

Submission, decisions, resolution, Shopify execution outcome, and exposed native-refund bypass events are recorded.

Shopify limitations

The native Shopify Refund button is not globally blocked. Refunds created directly in Shopify or another app may be detected only where Shopify exposes the event.

Troubleshooting

Check Overview for reconnect or permission issues, confirm the protected refund rule exists, confirm an approver is available, and inspect Activity for the exact execution outcome.

What this protects

Supported high-value or risky orders by placing a Shopify fulfillment hold, plus protected cancellation and address-change workflows.

When it triggers

An enabled Store Guard rule matches a supported order or an operator starts a supported protected action.

What the requester sees

The order, hold/request state, reason, and the next required decision.

What the approver sees

Order context, the requested operation, assigned approval policy, and available decision controls.

After approval

For a held fulfillment, Obsidian Guard attempts release after approval. For supported cancellations or address changes, it attempts the approved Shopify operation.

After rejection

The protected operation does not proceed. A fulfillment hold remains until it is separately and safely resolved.

If execution fails

The failure is recorded. Keep the order paused when possible, inspect Shopify, and follow the manual-recovery guidance before another release or change attempt.

Activity history

Hold placement, approvals, release attempts, cancellation/address outcomes, exposed direct actions, and failure/recovery state appear in Activity.

Shopify limitations

Hold and release depend on Shopify fulfillment state, permissions, and API behavior. Direct native operations can remain possible.

Troubleshooting

Confirm the Store Guard plan, rule, Shopify scopes, fulfillment state, and approver assignment. For release failure, inspect Shopify before retrying to avoid duplicate action.

What this protects

Operational review of address, order, discount/total, and shipping-method changes after payment, together with bypass and controlled-exception workflows.

When it triggers

Shopify exposes a supported post-payment change, a detected event enters bypass review, or an approved Control Guard policy creates an exception/review path.

What the requester sees

For controlled requests, the request and approval state. Detected events instead appear as activity requiring review or acknowledgement.

What the approver sees

Available Shopify/source evidence, policy context, approval-group requirements, escalation state, and the permitted review action.

After approval

Controlled actions proceed only where an execution path is implemented. Review-only or detected events are resolved as reviews and do not reverse Shopify automatically.

After rejection

The controlled request does not proceed. A detected event remains historical evidence and may still require remediation in Shopify.

If execution fails

The event or request records failure/manual-follow-up state. Escalation and urgent alerts can notify configured reviewers but delivery is not guaranteed.

Activity history

Change evidence, source attribution when available, bypass review, decisions, exceptions, reports, and exportable audit records are retained in the workspace.

Shopify limitations

Post-payment detection depends on Shopify event data. Attribution can be incomplete, and detection is not universal prevention or interception.

Troubleshooting

Confirm the Control Guard plan, enabled policy, Shopify scopes, approval-group membership, and the event's source evidence. Use Activity and audit export when escalation is needed.

Primary and secondary channel behavior depends on notification preferences and available destinations. When a channel is unavailable, suppressed, or exhausted, other configured channels may continue; no channel is guaranteed.

Upgrades apply the new capability set after entitlement activation. Downgrades can disable action families or configuration above the new plan. Existing request history remains; in-flight requests and held fulfillments remain in their current execution state so they can be resolved deliberately.

Shopify reconnect required

Open Overview and complete the reconnect action. Do not assume protected execution is ready until the status clears.

Missing Shopify permissions

Review the missing-scope message and reconnect through the approved install path. Protected execution stays unavailable until verified.

Refund rule missing

Open Protection and configure or restore the protected refund rule before submitting through Refund Guard.

Approver unavailable

Open Approvers, confirm an active reviewer is assigned, and invite or restore access within the plan limit.

Refund execution failed

Inspect Activity and Shopify order state. Do not retry blindly; follow the displayed manual-follow-up guidance.

Fulfillment hold failed

Keep the order from advancing through other automation when possible. Confirm fulfillment state, permissions, and the failure record.

Fulfillment release failed

Inspect the hold in Shopify before another attempt. Escalate if the order remains held after approval.

Native action detected

Review the event evidence and any related pending request. Detection records the bypass; it does not automatically reverse it.

Mobile alert limit reached

SMS and WhatsApp pause until reset or allowance changes. Confirm an email, Slack, or Web Push fallback if operationally required.

Notification not received

Check recipient details, preferences, channel setup, browser permission for Web Push, and the recorded delivery attempt.

For unresolved issues, use the in-product report path when available or contact support. Include the request/event identifier and timestamp, but never send API keys or Shopify tokens.

Obsidian Guard accesses Shopify identity, store, order, refund, fulfillment, and event metadata needed for enabled controls and operational evidence. Available fields depend on approved Shopify scopes.

The service stores account/workspace records, workflow and reviewer configuration, protected requests, decisions, execution outcomes, detected-event evidence, notification preferences/delivery state, entitlement state, and operational security records needed to run and support the product.

Do not place secrets, full payment-card data, or unnecessary customer data in request descriptions, webhook URLs, support messages, or notification destinations. See Security and the Privacy Policy for reporting and lifecycle information.