NORVANEO / AUTOMATIONS

Purposeful automations

Seven ways to reduce repetitive work. Explore requirements, test an example and choose what is worth implementing.

Implementation guide · nothing is active

These recipes are guidance, not installed integrations. The theme does not read orders in the background, send messages or schedule tasks. Any implementation needs configuration, permissions, tests and approval.

Diese neuen Werkzeuge sind auf Englisch und Portugiesisch verfügbar. Die Oberfläche wird auf Englisch angezeigt.

ALow stock → replenishment task

Trigger: Available inventory changes at an authorised location.
Conditions and exclusions: Monitored SKU, correct location and quantity at or below the threshold. Exclude discontinued or untracked items.
Intended action: Create an internal task with SKU, location and quantity. Do not purchase stock, change prices or place orders.
Data and integrations: Variant ID, location, stock and threshold. Shopify Flow and an approved task destination; a durable record tracks the alert cycle.
Acceptance test: Stock 3, threshold 5: one task. Repeat the event: no duplicates. Stock 8 closes the cycle; a later drop can open a new task.
Duplicates, errors and pause: Key: store + variant + location + cycle. Retry destination failures with the same key and a bounded attempt count. Recheck stock before acting; pause in the workflow.
Costs and limits: Check Flow plan, event volume and destination costs. The demo below is local and free; it does not install this integration.

Request implementation · A ↗

BOverdue order → exception queue

Trigger: Scheduled check of paid, unfulfilled orders after the agreed deadline.
Conditions and exclusions: Exclude cancelled orders, preorders and justified holds. Recheck payment and fulfilment immediately before the alert.
Intended action: Add to the internal queue with reason and owner. Do not cancel, refund or promise the customer a delivery date.
Data and integrations: Order ID, timestamps, states and hold reason. Authorised Flow or scheduled service; avoid copying addresses and payment data.
Acceptance test: An overdue order creates one exception; an order fulfilled between query and action creates no alert.
Duplicates, errors and pause: Deduplicate by order and exception type. A query error does not mean no overdue orders: show partial coverage and alert the operator. Pause in the scheduler.
Costs and limits: Costs depend on query volume, order permissions and destination. Define short retention and restricted access.

Request implementation · B ↗

CIncomplete product → catalogue review

Trigger: A product is created or relevant fields change.
Conditions and exclusions: Validate only agreed rules: title, images, description, price or category-required fields. Distinguish intentional drafts.
Intended action: Create a task and, if approved, a review tag. Do not invent facts, publish, delete or silently change the product.
Data and integrations: Product ID, rules, checked fields and analysis version. Flow and an internal queue; Catalogue Doctor can support manual CSV review.
Acceptance test: A product with two findings creates one combined task. A tag created by the workflow must not trigger an endless loop.
Duplicates, errors and pause: Deduplicate by product and relevant version; ignore self-generated tag changes. Recheck before closing. Pause if volume exceeds expectations.
Costs and limits: Cost varies with products, rules and connectors. Catalogue writes require explicit permission and scope.

Request implementation · C ↗

DQuote request → organised brief

Trigger: Confirmed receipt of a valid quote request form.
Conditions and exclusions: Required fields, contact consent, antispam checks and no duplicate. Do not subscribe to a newsletter by default.
Intended action: Create an approved CRM record with source, scope, deadline and missing information; prepare a reply draft for human review.
Data and integrations: Minimum necessary contact information and request content. Server-validated form and CRM connector; the theme alone does not create CRM records.
Acceptance test: A legitimate request is received once; a retry does not duplicate it. Spam is held. A CRM failure must not show a false record confirmation.
Duplicates, errors and pause: Server-side submission key and durable outbox. Retry transient failures within a limit; permanent failures go to review. Disable the connector without losing requests.
Costs and limits: Approve CRM plan, connector, hosting and retention. Submitting the form never automatically accepts a contract or reserves a date.

Request implementation · D ↗

EOperational summary → contextual readout

Trigger: Approved schedule, with explicit timezone and reporting period.
Conditions and exclusions: Identify every authorised source. Distinguish missing data, real zero, freshness and partial coverage.
Intended action: Prepare a summary of exceptions and defined indicators with source links. Do not invent revenue, savings or outcomes.
Data and integrations: Necessary aggregates, period and sources. Reporting service or Flow with supported queries; approved recipients, no unnecessary personal data.
Acceptance test: Compare totals with the source for the same period. Simulate an unavailable source: the report must disclose the gap.
Duplicates, errors and pause: Key by store + period + version. Retry only failed sources; deduplicate delivery. Pause scheduling and distribution separately.
Costs and limits: Queries, history, generation and delivery may incur costs. Define limits before promising frequency or timing.

Request implementation · E ↗

FDigital purchase → verifiable access

Trigger: Server-validated payment event; also reconcile cancellations and line-item refunds.
Conditions and exclusions: Verify signature, store, order, line item, product and owner. Guests need a validated identity-claim process.
Intended action: Record access rights server-side and send the secure link once. Marketing consent is separate.
Data and integrations: Identity, order/line item, grant and reconciliation state. Delivery app or secure backend; localStorage is never proof of purchase.
Acceptance test: Test payment, duplicate event, guest claim and partial refund. Email failure must not duplicate rights or expose protected content.
Duplicates, errors and pause: Idempotency by line item and event type; retry queue and manual review. Pause deliveries without deleting purchases. Reconcile state with Shopify.
Costs and limits: Validate app, backend, email and maintenance costs. This theme preserves existing access; it does not install this service or reconcile purchase history.

Request implementation · F ↗

GSupport request → assisted triage

Trigger: A new request arrives through an authorised support channel.
Conditions and exclusions: Defined antispam, purpose and retention. Uncertain classification or sensitive content goes to a person.
Intended action: Classify and draft a reply based only on approved policies. Do not send automatically, promise deadlines or issue refunds.
Data and integrations: Request ID, minimum necessary text and versioned policies. Approved helpdesk; AI use and third-party sharing need a separate assessment.
Acceptance test: A clear request is classified; an ambiguous request is escalated. Malicious instructions in the text never change rules, permissions or recipients.
Duplicates, errors and pause: Deduplicate by message and policy version. After failure, retain the request and flag review; do not send the same draft twice. Pause assistance without stopping support.
Costs and limits: Helpdesk, volume and optional AI carry costs and limits. Approve providers, access and retention before using real data.

Request implementation · G ↗

Fictional example

Try fictional stock

Local demonstration, not connected to inventory. One task per SKU/location until stock recovers. It does not store or send data; reloading the page clears the example.

No fictional events yet.

Safe implementation

Start with test data and one accountable owner. Enable production only after confirming scope, costs, permissions and rollback.

Define the event, minimum fields and who may see results.
Test success, repeated events, missing data, failure and recovery.
Recheck the source before every action. Log attempts without sensitive data and provide a pause control.
Review volume, cost and real outcomes regularly. Never promise execution while the integration is disabled.

Shopify Flow is a Shopify app, not a proprietary Norvaneo feature. Plan, permissions, connectors and limits must be checked before implementation.

Official Shopify Flow documentation ↗