How to Request Reviews After an In-Store Pharmacy Purchase

Build a Spojit workflow that runs each morning, finds yesterday's completed retail sales, and emails each customer a friendly link to leave a store review.

What This Integration Does

Asking for a review a couple of days after a purchase is one of the most reliable ways to grow your store's reputation, but doing it by hand does not scale. This tutorial builds a workflow that gathers recently completed retail sales, filters them down to genuinely fulfilled and non-refunded orders, and sends each customer a single review-request email with a link. Everything here is strictly retail and admin: the message references the in-store visit and the purchase, and never any prescription, medication, or clinical detail. The customer simply gets a "thanks for shopping with us, would you leave a review?" note.

A Schedule trigger fires every morning on a cron you set. A Connector node pulls the relevant orders, either from your online store via the shopify connector or from a point-of-sale system that has no native tile via the http connector. A Condition node keeps only the orders worth contacting, a Loop node walks the list one customer at a time, and a Send Email node delivers the request. The workflow is read-and-notify only: it does not change any order, so re-running it is safe as long as you scope the date window so the same sale is not picked up on two different days.

Prerequisites

A Spojit workspace where you can create and enable workflows.
One of the following order sources: a shopify connection (API key connection with read access to orders and customers), or the base URL plus API credentials for your point-of-sale system's REST API, reached through the built-in http connector.
A live store-review link (your Google review URL, a review platform URL, or a page on your own site).
Customer email recipients allowed under Settings > General > Email recipients if your org enforces an allowlist, since the built-in Send Email node respects it.
The IANA timezone for your store (for example Australia/Sydney) so the schedule and date math line up with your trading day.

Step 1: Start the workflow each morning with a Schedule trigger

Add a Trigger node and set its type to Schedule. Schedules use a 5-field Unix cron expression plus a timezone. To run at 8:00 AM every day, set the cron to 0 8 * * * and the timezone to your store's zone, for example Australia/Sydney. Running mid-morning gives buyers a day or two to settle in before you ask. The trigger output is simply {{ scheduledAt }}, which you can use as the reference point for "yesterday".

If you only want weekday sends, use 0 8 * * 1-5 instead. A single Schedule trigger can hold more than one schedule if you later want a second send time.

Step 2: Work out the date window

Add a Connector node on the date connector in Direct mode and select the subtract tool to compute the start of the lookback window. Subtract a small number of days from {{ scheduledAt }} (for example 2 days) so you contact people roughly two days after their visit. Store the result in an output variable such as windowStart. You will pass this value into the order query in the next step so you only pull recently completed sales rather than your whole order history.

Keep the window narrow and aligned with how often the workflow runs. If it runs daily, a one-day slice (for example sales completed two days ago) avoids contacting the same customer twice.

Step 3: Fetch recently completed sales

Add a Connector node in Direct mode for your order source.

If your sales live in Shopify, choose the shopify connector and the list-orders tool. Filter to recent, fulfilled, paid orders and pass your windowStart value into the date filter so the connector returns only the window you care about. Map the returned orders into an output variable such as orders.

If your sales live in a point-of-sale system with no native tile, use the http connector and the http-get tool to call that system's REST API directly. This is the supported pattern for any system Spojit has no dedicated connector for. Configure it roughly like this:

Tool: http-get
URL: https://api.yourpos.com/v1/sales?status=completed&since={{ windowStart }}
Headers:
  Authorization: Bearer YOUR_POS_API_KEY
  Accept: application/json

Store the response body in an output variable such as posResponse. For a deeper walkthrough of authenticating and shaping calls to an external API, see the related tutorial linked at the end of this article.

Step 4: Normalize the order list into a clean array

Different sources return their data in different shapes, so reshape it into one simple list before you filter. Add a Connector node on the json connector in Direct mode and use the get tool to pull the array of sales out of the raw response (for example the sales or orders array), then the pick tool to keep only the fields you need per record: an email address, a customer first name, an order or receipt number, the fulfillment status, and a refunded flag. Save the cleaned list in an output variable such as cleanOrders. Working from a predictable shape keeps your Condition and email templates simple no matter which source fed the data.

Step 5: Filter to fulfilled, non-refunded orders

Add a Loop node set to ForEach over {{ cleanOrders }} so each record is evaluated individually, and name the loop item order. Inside the loop, add a Condition node that only continues when the sale is genuinely complete and was not returned. Use an AND of two checks:

{{ order.fulfillmentStatus }} equals "fulfilled"
AND {{ order.refunded }} equals false

Also make sure an email address is present before you try to send. Records that fail the Condition simply skip the email step and the loop moves to the next customer. This is what keeps you from asking for a review on a sale that was cancelled, refunded, or never handed over.

Step 6: Send the review-request email

On the true branch of the Condition, inside the loop, add a Send Email node. This uses Spojit's built-in mail service, so no extra connection is needed. Set the fields like this:

Recipients: {{ order.email }}
Subject: Thanks for shopping with us, {{ order.firstName }}
Body:
  Hi {{ order.firstName }},

  Thanks for visiting our store recently (order {{ order.orderNumber }}).
  We'd love to hear how it went. If you have a moment, please leave us a
  quick review:

  https://your-review-link.example.com

  Thank you,
  The Team

Keep the copy retail-only: thank them for the store visit and the purchase, and point them at the review link. Do not reference any prescription, medication, or health detail. Set If sending fails to Continue anyway so a single bad address does not stop the rest of the run.

If you would rather send from your own verified domain instead of Spojit's built-in service, swap the Send Email node for a Connector node on the resend connector in Direct mode using the send-email tool, mapping the same recipient, subject, and body fields.

Tips

Send mid-morning, two or three days after purchase: long enough that the customer has used what they bought, soon enough that the visit is fresh.
Use the date connector's format tool if you want a human-readable purchase date in the email body.
If your order source paginates, request a generous page size or loop through pages, because a one-day window for a busy store can still exceed a single page.
Ask Miraxa, the intelligent layer across your automation, to scaffold this for you. Try a prompt like "Add a ForEach Loop over {{ cleanOrders }} with a Condition that checks {{ order.fulfillmentStatus }} equals fulfilled, and connect the true branch to a Send Email node." Then fine-tune the fields in the properties panel.

Common Pitfalls

Timezone drift: if the Schedule timezone and your store's trading day disagree, your "yesterday" window can miss or double-count a day. Set both to the same IANA zone.
Re-contacting the same buyer: overlapping date windows on consecutive runs will email a customer twice. Keep the window tight and aligned to the run frequency.
Refunds that land after the sale: a sale can be marked fulfilled and then refunded later. Always include the refunded check in the Condition, not just the fulfillment status.
Allowlist blocks: if your org enforces an email recipient allowlist, external customer addresses must be permitted under Settings > General > Email recipients, or the built-in Send Email node will not deliver.
Crossing the retail line: never let the subject or body reference anything clinical. Keep it to the visit, the order number, and the review link.

Testing

Before you enable the schedule, validate on a tiny scope. Temporarily narrow the order query to a single recent test order (or hard-code a one-record cleanOrders list), set the recipient to your own inbox, and run the workflow with the Run button. Confirm the Condition lets the record through, the email arrives, and the order number and first name render correctly. Check the execution log to see exactly which records passed the filter and which were skipped. Once a single pass looks right, widen the query back to your real window and turn the schedule on.