Building Rules

This page walks through the Rules page (Admin → Rules), where administrators create and manage the rules described in Rules & Quotas Overview.

The Rules list#

Open Admin in the sidebar, then choose Rules. You’ll see:

• A search box and tag filters to find specific rules.
• A table of rules, with columns for:
  • Name: the rule’s name and description.
  • Requirements: badges showing what this rule produces (for example, approver, max_cost).
  • Tags: labels you’ve added to organize related rules.
  • Scope: the site this rule applies to, or “Global” for all sites.
  • Priority: a number used for display ordering (higher numbers appear first; every matching rule is still enforced).
  • Status: “Enabled” or “Disabled”.
• A Rule set summary card showing how many rules are shown and how many are enabled vs. disabled.

Select New Rule to create one, or the pencil icon on an existing rule to edit it. The trash icon deletes a rule (with a confirmation, since this affects job evaluation immediately).

The rule editor#

Creating or editing a rule opens a full-page editor with two parts: a Details panel on the left, and Conditions / Requirements / Preview tabs on the right.

Details panel#

Field	Description
Name	A short, descriptive name (for example, “Large jobs need staff approval”).
Description	Internal notes about why this rule exists: visible only to administrators.
Site scope	Apply this rule to one site, or choose “Global (all sites)” to apply it everywhere.
Priority	Controls display ordering when rules are listed and previewed. Higher numbers come first; priority never changes which rules are enforced.
Tags	Free-form labels (for example, “after-hours”, “large-job”) to group related rules.
Message to user	Shown to the submitter on both the web and station checklists, explaining why this requirement applies. For a deny requirement, this is the primary explanation shown when the job is blocked. It is shown only once the rule has actually matched; see Rules that depend on something Pluraprint doesn’t know yet.
Enabled	Disabled rules are completely ignored: as if they didn’t exist.

Conditions tab: “when does this rule apply?”#

If you leave the condition empty, the rule fires on every job. Otherwise, you build a condition out of one or more checks, optionally grouped with all of (AND), any of (OR), or not.

Adding a check#

Each check has three parts:

1. Field: what to look at, organized into groups:

   Group	Example fields
   Job	Estimated duration, estimated material, estimated cost, file size, printer model, is reprint, site, definition completed at
   Slicer settings	Infill density (0–100%), supports enabled, layer height (mm)
   Materials	Material type used (for example, PLA, ABS, or ASA), whether material details are available
   Owner	Owner identified, owner’s roles, how the owner was identified (card, sign-in, PIN, automatic, admin override)
   Source	Submission source (Web, Station, API/Integration)
   Queue	Jobs currently waiting, estimated wait time
   Time	Hour of day, day of week
   Action	Action source, how the acting user was identified

2. Operator: how to compare it, in plain language:

   Operator	Meaning
   equals / does not equal	Exact match
   greater than / less than / greater or equal / less or equal	Numeric comparison
   is between	Numeric range (inclusive)
   is one of / is not one of	Match against a list of values
   matches	Matches a regular expression (for advanced use)
   is known / is unknown	Whether this field has a value yet

3. Value: entered with a widget appropriate to the field (a dropdown for roles or sites, number fields with the correct units and limits, a checkbox for true/false, etc.). Infill density is entered as a percentage from 0 to 100, and layer height is entered in millimeters.

Optional slicer metadata#

Infill density, support generation, and layer height are extracted from Orca 3MF project settings when the file contains them. Other file processors may not provide these values. Pluraprint handles an unavailable value explicitly:

• A normal comparison such as Infill density greater than 30% evaluates to Unknown. This is conservative: the job remains in definition review instead of bypassing a restriction that Pluraprint cannot verify.
• is known matches only when the value is available; is unknown matches only when it is absent.
• To skip a threshold rule when metadata is absent, create an all of group containing Infill density is known and Infill density greater than 30%. The first false check makes the whole group false for files without that metadata.
• To require review whenever metadata is absent, add a separate rule with Infill density is unknown and produce the appropriate approval or deny requirement.

Material conditions use the material labels reported by the slicer. To restrict ABS and ASA, choose Material type used → is one of and enter ABS and ASA. The condition matches if the job uses either material.

Grouping conditions#

Use the + Add group button to nest conditions:

• all of: every condition inside must be true (AND)
• any of: at least one condition inside must be true (OR)
• not: inverts the result of what’s inside

Each check or group can be reordered, duplicated, or deleted using the icons on its card.

Requirements tab: “what must be satisfied?”#

This tab defines what gets added to a matching job’s checklist. Select + Add Requirement and choose a type:

Requirement	What it adds to the checklist
Owner Identified	The job must have a known owner (someone identified at web or a station) before it can queue.
Owner Has Role	The job’s owner must hold a specific role (e.g., “staff”): including roles that inherit from it.
Approval	A person must approve the job. You can set a label (for multi-stage approvals), an optional time limit (SLA), and constraints: required/forbidden roles or specific users who may approve, and whether the requester can approve their own job.
Identification Required At	The job’s owner must be identified at a specific location: Web or Station.
Definition Required At	The job’s print settings (definition) must be completed at a specific location: Web or Station.
Maximum Duration	Caps the job’s estimated print time (hours and minutes). Jobs over the limit are blocked.
Maximum Material	Caps the job’s estimated material usage (in grams).
Maximum Cost	Caps the job’s estimated cost.
Deny	Blocks the job outright, with a reason shown to the user (and an optional code for integrations).
Custom	A requirement satisfied by an external system or integration, identified by a key, with a message and optional link shown to the user.

Each requirement type’s card explains what it does and shows only the fields relevant to it. Pluraprint prevents a rule from being saved with duplicate requirements, empty condition groups, unknown field names, incompatible operators, or invalid regular expressions. These checks also run for rules created through the API, not only in the visual editor.

Preview tab: test before you save#

The Preview tab contains a full rule tester. There are no built-in sample scenarios. You create cases that represent how your organization actually works. A case can start from a real print job, which loads the same job, queue, identity, approval, site, and slicer context used by production evaluation. You can then override any value without changing the real job.

Use the three case tabs to test:

• Identity & approvals: anonymous or identified owners, the identifying user and method, effective roles, and any number of labelled approvals by different users.
• Job: name, estimates, file size, printer model, reprint state, site, definition location, materials, and optional slicer settings.
• Where & when: submission and action sources, site and station, queue counters, exact time, hour, and day of week.

Optional values can deliberately be left Unknown. This is useful for checking partial kiosk and web submissions before the owner, definition, or slicer metadata is available. The result shows every rule as Matched, Not matched, or Unknown, lists the fields behind an Unknown result, and renders the cumulative requirements checklist.

Name and save cases you expect to reuse. Saved cases stay in the current browser and can be duplicated as a starting point for boundary tests. Select Test rules from the main Rules page to open a dedicated tester with the same cases and controls. It evaluates the complete active global-and-site rule bundle; list filters and pagination do not limit that test.

Tips for writing rules#

• Start narrow. A rule scoped to one site or tagged for testing is easier to reason about than a global rule.
• Use the message field. The “Message to user” text is what your team will actually see on both web and station checklists: make it explain why the policy applies and what to do next, not merely that the job is blocked. Write it in the present tense, for someone the rule has already matched (“Your account is suspended; see the lab desk”): Pluraprint withholds it until the rule is decided, so it never has to hedge on your behalf.
• A rule about the owner needs the owner. A condition on the job owner’s role or identity can’t be judged until they’ve signed in or tapped a card. Such a rule shows as may apply and forces identification first, rather than being treated as a match or a non-match. Pair it with an Owner Identified requirement if you want the prompt to be explicit.
• Remember rules combine. If a job matches three rules that each require approval, it will enforce all three. Requirements deduplicate only when their complete configuration is identical. Reusing an approval label with different constraints does not discard either constraint; use distinct labels when you intend separate approval stages.
• Disable instead of delete while testing changes. You can re-enable a rule instantly, but deleting it is permanent.