Actions — what a rule can do

Step by step

The Add informational packing item action appends custom text to the end of the goods list in the WMS2 kiosk. Available types are information, warning, free gift, and leaflet / insert. None requires scanning or confirmation; configuration is described in Information, warning, free gift, and leaflet on the packing list.

Add an action to a rule

1. Go to Tools → Automation → Rules and open a rule (click its row), or create one with New rule.
2. Select an event in Choose event.... Until you do, the right-hand column says First choose a trigger to add actions. (Events — what starts a rule).
3. Under the Action heading, click the round + button (Add action). An action card appears with its position number.
4. Expand Choose action.... The list is grouped: actions for the trigger’s domain, plus Works with any trigger (which includes Send notification (Email/SMS/In-app)). Actions you are not authorised to use do not appear in this list; see the procedure below.
5. Fill in the parameters shown under the selector. They depend on the action.
6. Add more actions with the same + button. Change their order with the arrows in the card header or by dragging a card using the handle on the left (Drag to change order). The badge number is the order in which the action runs.
7. The hand icon in the card header controls what happens after an error. Off: Continue workflow even if this action fails. On (red): Stop workflow if this action fails.
8. The gear icon (Action settings) opens two settings: Wait before running (No wait, 5 minutes, 15 minutes, 30 minutes, 1 hour), with the hint The rule pauses here and continues after this time. Actions below wait with it.; and, for actions other than the first, Run when (Always / If previous succeeded / If previous failed) and Track action.
9. Click Save (or Save changes). Saving rules is protected by two-factor verification. If the sensitive-operations session has expired, enter the Verification code in the 2FA verification required dialog and click Confirm (you then have 15 minutes without another prompt). Success message: Rule created! or Rule updated!.

Saving with no actions produces Add at least one action!. If an action has incomplete fields, you see Complete or remove incomplete action fields.

Grant permission to a protected action 🔒

1. Go to Configuration → Team and access → Roles and permissions.
2. Open a role for editing (click the pencil in its row → Edit role).
3. On the Module permissions tab, make sure the role has Read access to the Automations module. Without it, field permissions will not work and the automation screen will not open. (Before Automations had its own module, Settings served this role; existing grants were migrated automatically.)
4. Open the Field permissions tab.
5. Expand Rule actions. You will find seven entries:
   • Workflow > Action: send shipment numbers to marketplace
   • Workflow > Action: send invoice to marketplace
   • Workflow > Action: change marketplace status
   • Workflow > Action: export invoice to accounting system
   • Workflow > Action: fully refresh order from marketplace
   • Workflow > Action: send orders to wholesaler
   • Workflow > Action: cancel orders with wholesaler
6. Select Write for the actions the role should be allowed to add to rules. The Write column, not Read, controls whether an action is available in the rule builder.
7. Click Update role and confirm the code in the 2FA verification required dialog.
8. To check it, a user with that role goes to Tools → Automation, opens a rule, and expands Choose action.... The action should now be listed. If it is still missing, the permission was granted to a different role from the one assigned to that user.

Modify order is handled separately: when a rule is saved, the system checks permissions for the specific order fields selected in that action, not one permission for the whole action.

Orders and marketplace

🔒 = requires a separate permission.

Send order to wholesaler sends the order to the wholesaler connection selected in Wholesaler connection — Halmar or Signal. Each order is sent only once: running the rule again succeeds without placing another order, and before sending anything the action asks the wholesaler whether it already has the order. The wholesaler packs the goods and ships them with its own carrier (its consignment number is later returned to the order) or with your carrier. In the latter case, the order is sent only after you book a shipment with your carrier from the wholesaler’s warehouse, together with the wholesaler’s labels. When the connection sends the wholesaler’s part of a mixed order, the wholesaler receives only items from its warehouse and you ship the rest. The action does not send a mixed order when the connection does not split it; an order cancelled by you or on the marketplace; an order for a pickup point; a COD order if the connection does not send COD; an order already closed by the wholesaler (rejected, withdrawn, or without a consignment number or import within the time limit); an order with your carrier’s shipment at a wholesaler that ships itself; or an order without a booked shipment from your carrier at a wholesaler that uses your carrier. In these cases it creates a notification and fails. Therefore leave Continue workflow even if this action fails on, and add an action with Run when set to If previous failed to move the order to a status for review. If the order is later sent to the wholesaler, these notifications close automatically. Ready-made rules are described in Halmar — connecting a furniture wholesaler and Signal — a furniture wholesaler that ships with your carrier.

Cancel order with wholesaler withdraws an order from the connection selected in Wholesaler connection, as long as the wholesaler has not started processing it. The system asks the wholesaler to remove the order and checks that it really is gone. If the wholesaler is already preparing or has shipped the order, has not returned it, or has not confirmed withdrawal, the order gets a Wholesaler: cancel the order with the wholesaler manually notification and the action fails; cancel it with the wholesaler yourself. The same applies to a wholesaler that does not accept system withdrawals (Signal): cancel every order sent there manually. If withdrawal later succeeds, the notification closes automatically. The action skips an order that was never sent to the wholesaler (and is not there) or was already withdrawn. This is not an error, so it does not run actions configured for success or failure.

Both actions work only while the wholesaler connection is enabled. If it is disabled — or the sales-channel connection the order came from is disabled — the entire rule is skipped: its execution history shows SKIPPED, it creates no notification, and it does not run actions configured for failure (Execution history — what really happened).

Add internal note requires permission to write to the order description. Enter the text and, optionally, turn off Add date and time. The entry is appended after a blank line; the customer note is unchanged. An identical most recent entry is not added again, even if the date has changed. A different note allows the previous text to be added again. The entire description, including dates and separators, is limited to 1,000 characters; exceeding the limit fails the action without truncating text. The save is recorded in history as an automation and emits Order edited. The action is installed by workflow migration 0098_fulfillment_automation.

Add product to order requires create permission in the Orders module. Search by SKU, EAN, or name (at least two characters), choose a fulfilment warehouse, and enter a quantity from 1 to 1,000, a gross unit price in the order currency, and a VAT rate. A price of 0 means it is free. The action creates a goods line handled by WMS; adding it also updates an existing active queue in the selected warehouse. Cancelled or already fulfilled orders cannot accept these lines. If the order is already in WMS, there is no queue for the selected warehouse, or task creation fails, the addition is rolled back and an error is reported. A retry fills in missing tasks for the previously added line without increasing its quantity.

Example rule: Any item has fulfilment warehouse X and the reversed condition Order contains a product matching the criterion (product ID Y) → Add product Y, quantity 1, warehouse X. Reversing the condition checks that the product is absent. The action itself also skips adding the product if an item with a positive quantity already exists in any warehouse on the order; running it again does not increase the quantity. A refresh from the marketplace preserves the added item and includes its value in the order total. This feature requires orders migration 0114_orderproduct_added_by_workflow and workflow migration 0098_fulfillment_automation.

Retry product matching is for orders held in the issue product empty status (an item had no matched product on import; on Zalando, this is most often a temporary EAN-reading error). The action downloads the order again from the marketplace and matches lines without a product, just like the Products option in Refresh from marketplace on the order page. When every line has a product, it closes the product empty notification, moves the order to the status selected in the rule (an empty field means the entry status default), and emits a new-order signal, so later rules treat it as new. If an item still has no product, the order remains in the hold status without a new notification.

Recommended rule: trigger Internal status changed to issue product empty, condition Internal status = issue product empty, and three copies of the action with delays of 0 s, 900 s, and 900 s. After a successful release, the condition is no longer met, so later attempts do not run. After three failed attempts, the order remains for an operator.

Remove product added by automation removes every added line for the selected product, including lines split across warehouses. It does not remove items purchased by the customer. Inactive products are also available. If even one line to be removed has started in WMS, has been packed, or has shipped, the action fails without removing any of the others. The removal remains in history, updates the order total, and removes pending queue tasks. Running the action again after successful removal changes nothing. It requires Delete permission in the Orders module. Manually adding the same product creates a separate line and it remains when the add-on is removed.

Shipments

Cancel unused shipping labels lets you select the shipment from the event or the order’s outgoing shipments. It requires Delete permission in the Orders module. The action checks that packing has not started, no goods have been physically packed into parcels, the shipment has not been dispatched, and its tracking number has not been sent to the marketplace. A carrier notification that a shipment is registered does not by itself mean it has been dispatched.

The action uses cancellation confirmations from the UPS, Allegro Kurier, Ambro, Schenker, Geis, and InPost drivers. Carrier limitations still apply — InPost allows unconfirmed reservations to be cancelled here. Best-effort attempts, for example PostNord, are not sufficient for automatic label cancellation.

Before sending a request to the carrier, labels are disabled. Packing, printing, label creation, dispatch, and sending numbers to the marketplace are blocked while cancellation is pending and when the result requires checking. The local shipment is deleted only after every parcel’s cancellation is confirmed. Files and change history remain. An uncertain response or timeout keeps the shipment and blocks another cancellation request; check the result with the carrier and handle it manually on the order page. If cancellation was confirmed but local cleanup failed, a retry finishes cleanup without another carrier request.

WMS fulfilment conditions

• WMS fulfilment status — the status calculated as on the order page: picking, sorting, packing, packed, and other WMS statuses.
• Order is in an active WMS queue — at least one line with a positive quantity is in an active queue. The reversed condition checks that there is no such queue.
• Order packing has started — a packing operation in an active queue has started or finished, including when the first item has not yet been recorded.
• Order is partially packed — some quantity has been packed and some remains to be packed in active queues; this also works for a single partially packed line.

Conditions check the state when the selected trigger runs. They are not new triggers themselves. The new actions and conditions are installed by workflow migration 0098_fulfillment_automation.

Create shipment with carrier uses a specific carrier, optionally with a label. Create shipment according to mapping gets the carrier from the delivery-method mapping (Delivery-method mapping and shipment validation).

Both actions have a Label template field: From carrier mapping or a selected template (Label templates — what the company prints on parcels). Below it are parcel size, COD amount, and insurance; if the action has a carrier account selected, additional services are also shown. Change the sender and other account settings in the template, not in the action. All settings are visible immediately. Gray values come from the template. Change only what this action should do differently; ↺ restores the template value. An action with no overrides creates the shipment exactly as specified by the template.

If the template or action says Ask employee during packing, an action that creates a label does not create the shipment immediately: the order waits for packing, where an employee chooses the parcel size. An action that only prepares the shipment succeeds; the kiosk asks for the parcel size when it is confirmed.

If the order already has a label, the action does not create a second shipment. If the order has an outgoing shipment with a ready label (created manually on the order page, during packing, or by an earlier rule run), neither action calls the carrier. The history shows a successful result, and the order continues through the workflow. Without this protection, moving the order back to the rule’s trigger status would book a second shipment: its number would overwrite the parcel’s number, while the printed label had the first number — the marketplace would receive a number with no parcel attached. The action creates a shipment despite an existing label only when:

• the rule parameters contain force_new_parcel: true or use_existing: false, an explicit request for another shipment;
• creating multiple shipments stopped partway through, and the action is completing the missing ones.

Returns are not affected. Manually creating a label on the order page works as before; an employee can deliberately create another one.

Ship from wholesaler warehouse. Both actions also have a Ship from wholesaler warehouse field. Use it for goods at a wholesaler that ships with your carrier (Signal), on an order that also has items from your warehouse. With the field blank, the action creates your shipment as before. With a wholesaler warehouse selected, the action:

• creates a shipment for that warehouse — it never adds to your packing shipment;
• assigns order items from that warehouse to the first parcel;
• checks for an existing label only on shipments from that warehouse — your label does not prevent this shipment;
• gets the sender from the label template as usual (the warehouse address is used only when the template uses the warehouse as sender);
• refuses if the selected warehouse is your own or does not belong to the company, for a return, or for a COD order that already has another shipment: only one shipment can carry COD. The order gets a shipment-failed notification and the action fails.

You can make the same choice manually on the order page: if the order also has items outside the wholesaler warehouse and has not yet been sent to the wholesaler, the Create shipment panel asks Who is the label for? — Our warehouse (only if the order has your items) or Wholesaler: <warehouse>, with the wholesaler warehouse’s name. The Create label button in the wholesaler group on the order page opens this panel with the wholesaler warehouse already selected. Signal — a furniture wholesaler that ships with your carrier describes the ready-made rule and manual process for a mixed order with Signal.

Documents

Change document status · Create related document · Print document (on the workstation’s selected printer) · Generate order document (PDF without printing).

Returns

Change return status · Set return reason · Set customer-service status · Mark as problematic · Change order status from return.

Change order status from return moves the order associated with the return to the selected internal status — just like Change status for orders, using the same order-status list. The change is recorded in order history and triggers order rules configured for the new status, like any other order-status change. The action skips a return without an order and does not fail. Together with the Order from return: paid and Order from return: status conditions (Workflow conditions — every listed condition must be met), it lets you build a rule that changes the order after a return — for example, move an uncollected, unpaid COD order to a status for cancellation.

Mark returned goods as no credit note required · Remove the “no credit note” mark from returned goods — a pair of actions for goods put back on the shelf before the ERP receives the sales correction. Attach the first to return closure (it works only on a closed return), and the second to the status meaning “the correction is in the ERP” (in our system, KFS_Confirmed). Neither has parameters, and both can run repeatedly; without these rules there is no mark at all. They work only when Settings → Returns → General → Track goods without ERP credit note is enabled; when it is off, they do nothing (Goods without an ERP credit note — returned items on shelves before the ERP is updated).

Check ERP credit note

Searches the ERP selected under Settings → Returns → General → ERP credit-note verification (Subiekt GT or WAPRO Mag); the action does not select the ERP itself, but uses the configured one. It does not issue anything in the ERP, only reads. No credit note after (hours) specifies how long a return may remain in its current status without a credit note before the action fails; the hint says 0 = on the first check.

Use later actions to decide what happens next: set Run when to If previous succeeded (for example, Change return status to “reconciled”) or If previous failed (for example, Set Customer Service status), and set Track action to Check ERP credit note. Never choose Always — that would also run when the result is “not yet” or the ERP did not respond, which is every run. The wizard permanently displays this reminder beneath the action. For the check action itself, keep Continue workflow despite this action’s error enabled; otherwise, failure actions will not run.

When the result is neither success nor failure, the rule run is Skipped in execution history (Execution history — what really happened), including if the return was deleted during the check. A failure to save the result on the return never makes the action fail: failure actions would send a return that might have a credit note to Customer Service. The company gets an issue only if a connection problem prevents querying the ERP; a temporarily silent ERP and a problem reading one return’s documents do not create one (Return statuses, groups, and transitions).

Usually, attach the rule to Return status changed (check once on entry) or Cyclic: return in status (check each interval while the return remains there) — Events — what starts a rule. Configuration and rule examples: Return statuses, groups, and transitions.

The old Verify KFS credit note action has been removed. It checked only Subiekt and failed when Subiekt did not respond. During deployment, rules using it are migrated to Check ERP credit note. Until then, such a rule does not check anything: its execution history shows Skipped with Action definition '…' (…) is no longer available — re-point the rule. This is how every rule with a removed action ends — it must be repointed to another action.

Products and catalogue

Change product activity · Set ABC class · Add product to category · Remove product from category · Set product custom field (an empty value clears it) · Queue stock sync to marketplaces · Set minimum stock.

Warehouse

Create replenishment tasks · Create location stocktake (joins an existing one instead of duplicating it) · Approve stocktake automatically · Escalate stocktake · Move to status (when work is backed up).

Other

Send notification (email / SMS / in-app, using a template) · Wait (up to 60 minutes) · Call URL (webhook with a body) · Call custom event — that is, run another rule (Custom events — manually triggered buttons).

Notify everyone in a role

Choose the recipient with Recipient selection method. In addition to a manually entered address and addresses taken from an object (customer, account manager), there is Everyone in role: select a Role, and the message goes to every person in your company who has that role.

• Each recipient gets their own notification entry and message; this is not one message with a list of addresses in copy.
• People without an email address are skipped. Disabled (inactive) accounts are skipped too — a role may still include a former employee whose mailbox usually does not.
• If sending to one person fails, the others still receive their copies. The rule reports an error only if delivery to everyone fails.
• The Role field appears only after Everyone in role is selected; other recipient selection methods have nothing to configure there.
• The SMS channel does not support sending to a role.

This means “notify the warehouse” or “notify customer service” no longer requires copying a list of addresses into every rule: changing the membership of a role updates the recipients of all rules at once.

Call URL — webhook with a body

The action that used to be a stub now sends a real request. Its fields are:

Keep these rules in mind:

• A response other than 2xx is an action error — a rule set to “stop on error” really stops, and the history shows the response code and beginning of the body.
• Redirects are not followed.
• A body that cannot be populated (for example, {{ order.id }} in a rule without an order) stops the action. The system will not send a raw template to a partner who might mistake it for an order number.
• GET has no body.
• Host and Content-Length headers are rejected when saving.
• Amazon orders are sent without buyer data — first name, last name, email, phone, login, tax ID, and addresses (including those from a return or document) are inserted as blank. The order number, statuses, amounts, country, and shipment numbers remain. The rule does not stop.

Seven actions that require a separate permission

Actions marked 🔒 require a role grant in the Field permissions catalogue, in the Rule actions group under the Automations module (Field permissions — individual fields and individual actions). Previously, this group was under Settings; its permissions are migrated automatically, so you do not need to grant them to roles again.

Without this grant, the action does not appear in the rule builder. If you cannot find Send invoice, the likely cause is a missing permission, not a missing feature.

Modify order is additionally protected separately for each field — you may be allowed to change the comment but not the amount.

Two actions that do nothing

Do not build a process around these actions:

• Notify manager about stocktake — writes only a log entry; no one receives a notification.
• Generate ERP documents — a stub; it does not create any document.

Both end with a successful result in the history. Use Send notification to send a notification (Automation pitfalls).

A third action in this list used to be Call URL (formerly “webhook”), which failed on every run. It now sends a real request; see the description above.