Custom events — manually triggered buttons

Not every automation should run by itself. Sometimes you want a button that an operator deliberately presses — “send a reminder”, “prepare documents”, “send for a complaint”.

That is what custom events are for: you design the button, and a rule attached to the event does the rest.

Step by step

An event by itself is only a button. To make something happen, it needs a rule, so these are two procedures in sequence.

Create an event

1. Open Tools → Automation and go to the Custom events tab.
2. Click + in the list header (tooltip: “New custom event”).
3. Enter Event name and choose Applies to, the area where the button should work. This determines which interface locations are available.
4. Under Button, set Icon, Color and Button label. Use Preview beside them to check how it looks.
5. Under Where it appears, select Locations. You can also set a Keyboard shortcut: click the field and press the combination; you cannot type it in.
6. Leave Also trigger by scanning a barcode selected to get an automatically generated code. Fill in Barcode only if your warehouse already prints its own codes.
7. Under When to show it, restrict visibility to selected Statuses if the button is not relevant for every object. Add a Confirmation prompt for an irreversible action.
8. Click Save and confirm with the code in the 2FA verification required dialog.

Attach a rule and grant access

1. Return to Rules and create or open a rule.
2. In the Trigger step, expand the event list and choose yours. Custom events appear in their area group, after system events.
3. Finish and save the rule.
4. Open Roles and permissions and find the Manual triggers group in the field-permission catalog.
5. Select your event for the role that should use it, or choose All manual actions to grant the full set.
6. Make sure the same role has write access to the area's module. Without it, the button stays hidden even if its event permission is granted.

Until steps 4–6 are complete, only the company administrator can see the button. The event creation dialog says so and links to Open Roles.

Event settings

You can set its name, area, description, icon and color, button label, interface locations, optional keyboard shortcut, barcode, status-based visibility rule and confirmation prompt.

Enable a confirmation prompt for any irreversible action. The server checks it too, so it cannot be bypassed.

Where the button can appear

Not every area has every location. Orders have the full set; documents and returns have object lists.

Three areas — products, consolidated shipments and warehouse — can no longer be selected for custom events. They have no screen that can display the button, and the scanner cannot reach them either (the WMS2 kiosk scans orders). Saving an event for one of these areas shows a message naming the areas where it can appear. Previously, such an event could be saved but did nothing anywhere.

Existing events in those areas can still be edited — name, description and actions — as long as you do not change the area or locations. Otherwise they would be impossible to adjust: they cannot be deleted while a rule still refers to them.

A new event must have somewhere to appear: at least one Location or an enabled barcode. If neither is set, saving shows a message instead of creating an invisible button.

For the same reason, you cannot save an event with no locations and no barcode: nothing could trigger it.

Previously saved events in those areas remain untouched and editable (otherwise they could not be cleaned up while a rule refers to them).

Three ways to trigger it

1. Press the button.
2. Keyboard shortcut — works only in two locations: the list menu and the record action bar.
3. Barcode — generated automatically or entered manually. Entering your own code disables the generated one; from then on only yours works.

Triggering from a list covers at most 500 objects at once. Objects excluded by the status rule are skipped and reported separately.

Permissions — two gates

To see and press the button, a user needs both:

1. Write access to the area's module — orders, products, documents, warehouse or locations.
2. Separate permission for that specific event, granted in roles in the field-permission catalog, under Manual triggers (there is also an option covering all of them).

By default, only administrators can see anything; permissions must be deliberately granted (Field permissions — individual fields and individual actions).

Chaining rules

The Call custom event action — it has no translation and appears in English in the list — lets one rule trigger another. This helps split a complex process into clear pieces, but is also the easiest way to create an infinite loop (Automation pitfalls).

Deleting

You cannot delete an event used by a rule or called from another rule. Detach it from the rules first.

Deleting an event also removes permissions granted for it. Recreating the event does not restore those permissions; grant them again.