How steps fit into an automation
You create an automation on the Create Automations form, which has Name, Trigger and Enabled fields. You add steps only after you save the automation. Steps are the actions the automation runs.
Steps come in two kinds: those that read information and those that change something. A step that reads hands what it finds to the steps after it, so later steps can use those values.
Read a single record
Each step in this group starts from a reference to one record, such as a company or an order, and makes that record's values available to the steps that follow.
Get the company loads a single company, including values such as its credit limit and payment policy, for the steps that follow. Treat the credit limit and balance as a snapshot: they reflect the most recent customer sync, so a change made in the ERP since then is not yet visible.
Get the shopper loads one shopper, meaning a storefront login. Logins carry no name, so the name and company this step returns come from whichever ERP contact the shopper has selected. When a later step needs the shopper's company, pass the company id this step returns to Get the company.
Get the product loads the product details the client keeps on record. It leaves out a company-specific price and live stock, since those are questions for the ERP.
Get the order loads the order in the state it is in when the step runs. Put it after a Wait when you need to confirm that the order still awaits approval before a later step acts on it. Read a status of complete carefully: it tells you the order was released to the ERP, not that the ERP accepted it. The ERP's verdict is reported separately, as the ERP status. The platform keeps no record of whether or when an order was approved, so this step cannot give you that.
Get the employee reads an administrator, an agent or an implementer. Don't use its ERP agent flag to identify agents: the client's ERP sync sets it, so someone given the agent role in the admin panel is not flagged.
Each of these steps also tells you whether it found the record, and when it did not, all its other values come back empty.
Ask the storefront or the ERP
These steps put a question to the storefront or the ERP and pass the reply on to later steps.
Get the price tells later steps what one company pays for one product, drawing on the shop's price lists or on its ERP, depending on how the shop is configured. Expect a unit price that excludes VAT. If the company has no price for the product, the step reports it as not found rather than returning zero.
Get the stock returns the product quantity the storefront works with, whether the shop keeps that figure itself or takes it from the ERP. Orders still awaiting approval are already subtracted, so the figure can go negative when those orders exceed what the shop holds.
Get the basket's value returns the total that the basket page shows the shopper for an open basket. It works only on an open basket; for an order's total, use Get the order instead. Any line that has no price is excluded from the totals it returns.
Get the open items asks the ERP how much a company owes, which is the question behind the storefront's open items page. Owed nets the company's open documents, debits minus credits, and Overdue is the share of that amount already past its due date. A document counts as overdue only if the ERP records its due date complete with date, time and time zone; any other due date is treated as not overdue. This step is available only in shops whose ERP provides open items.
Because each of these questions is answered in the background, allow a brief delay, typically less than a second. If you follow one of them with Send the shopper to a page, the shopper is redirected on their next click rather than straight away.
Go through a list of records
Four steps search for records instead of reading one: Companies, Shoppers, Products and Orders. Each one runs inside a For each, whose conditions decide which records qualify. Every qualifying record is passed in turn to the steps nested in the loop, under a name you choose for one item. A run handles at most 100 matches, oldest first. With Go through all of them on, a run handles every match, up to 20 000.
Companies skips any company the ERP has deleted. As with Get the company, its credit and balance figures date from the latest customer sync.
Shoppers searches storefront logins. Names and companies again come from each shopper's chosen ERP contact, not from the login.
Products skips any product the ERP has deleted. The base price it gives you is the stored list price excluding VAT, not a company-specific price. To get what a company pays or how much is in stock, use Get the price and Get the stock inside the loop.
Orders finds placed orders and documents, and never finds a basket. With Go through each order once switched on, orders the loop processed in a previous run are skipped. If more than 100 orders qualify under that setting, the remainder are picked up by the following run.
Three other steps go through the parts of one record instead of searching. Each of them sits under a For each and hands the parts to the nested steps one at a time.
Contacts of the company walks through everyone the ERP lists as a contact for a single company. Contacts removed in the ERP are left out. For a contact with a storefront login, the item includes that login's shopper id, which you can pass to Get the shopper.
Lines of the basket walks through a basket's lines in the sequence they were added. Basket lines stay unpriced until the order is placed.
Lines of the order walks through an order's lines, following the sequence of the order page. Line prices are those charged at checkout, with the company's discount and tax not yet applied.
Change something
The steps in this group write a change instead of reading data.
Put a label on the product attaches a label the shop already has, adding it after any labels the product carries. If the product already has that label, nothing changes and the run notes it rather than reporting a failure. You choose which label when you build the automation, from the labels the client has, because the event does not carry it.
Take the product off the storefront switches on the product's hidden flag. Shoppers then no longer find it by browsing the catalog, searching, or opening a brand or collection list. Anyone with a direct link can still open its page. The step deletes nothing and sends nothing to the ERP. From then on, the automation keeps a hold on the product, even if it was hidden before the step ran, and only a Put the product back on the storefront step in the same automation releases it. When more than one automation has hidden the same product, it returns only after every one of them has released its hold.
Put the product back on the storefront switches the hidden flag off again. New steps have Only the ones this automation took off switched on. In that mode, the step first releases this automation's hold. The product reappears only if no automation still holds it and an automation, not a person, hid it in the first place. So a product that staff hid manually stays hidden. With the setting off, which is also how steps saved before it existed behave, the step shows the product whoever hid it and releases no hold. Running it on a product that is already visible is not treated as an error; nothing changes and the run notes it.
Approve the order lets an order that is waiting for approval go through to the ERP, and the order is marked complete. It is the automated equivalent of an operator pressing approve on the order. The step declines to approve in three cases: card payment is required but was not taken, the amount captured no longer equals the order's value, or the customer or contact is no longer in the ERP feed. Each refusal identifies the order and shows in the run as a failed step, not as a change.
Send the shopper to a page decides where a shopper lands right after signing in. The page you pick replaces wherever they would otherwise have ended up: the home page, the page that prompted the sign-in, or the account activation page. It works only with the Customer signed in trigger. Because it never redirects a shopper who is already browsing the shop, it cannot break into a checkout. Only pages that an implementer has flagged with Automations may send shoppers here in the site builder, then published and synced, are available as destinations. The step checks that page twice: when you save the step, and on every run. If the page was deleted or lost its flag in the meantime, no shopper is redirected, and the run log explains why. Plan for new registrations: a shopper who signed up on the storefront has not been activated by their first sign-in, so your page appears in place of the account activation page. Either offer account activation on that page, or use the Account is activated condition. Afterwards, the run log shows whether each redirect was delivered, is still waiting, expired, or was superseded by a newer instruction.
Sign the shopper out everywhere ends every sign-in the shopper holds, from that moment on. Each signed-in device is logged out the next time it makes a request. The account itself is untouched, and the shopper is free to sign back in straight away. It works only on shoppers; you cannot aim it at a member of the shop's staff.
Rebuild the storefront's cached pages asks the storefront to refresh its cached pages. Because it needs no record, it can follow any trigger. The run shows only that the request was made; the storefront completes the refresh afterwards.
Limits to plan around
A step can start another automation: taking a product off the storefront announces that it was hidden, and putting it back announces that it was shown. Because hiding and showing can set each other off, automations can trigger one another in a chain no more than three deep. Steps use personal details such as names, e-mail addresses and phone numbers, but never write them to the run log. The same holds for the note typed on a basket or order line: steps in the loop can use it, but the run log never shows it.
Related