The Policy Rules Editor is Reveni's advanced rules engine. We designed this tool to give you complete and independent control over your reverse logistics.

You are not limited by a standard returns policy; you have the freedom to create as many rules as you need to cover every imaginable scenario in your business.

While the Default Policy establishes the foundation for the bulk of your returns, Policy Rules act as layers of higher intelligence. They allow you to say "yes" to exceptions without compromising the general rule.

• Endless options: Want to offer free returns only to VIP customers on orders over €200? You can. Need to charge a cleaning fee only for silk dresses on sale? You can do that too.
• Total autonomy: You don't need to contact support for complex configurations. You imagine the rule, configure it, and activate it.

The power of this tool lies in its logical structure, designed to be hyper-specific: A rule consists of 1 Action (what happens) and N Conditions (when it happens). For the action to be executed, all the conditions of that rule must be met.

1 Action (The Effect) + N Conditions (The Context) = Infinite Possibilities

1. Single Action: You define exactly what you want to happen (block, charge, extend, pause).
2. Unlimited Conditions: Add as many filters as you want (country, customer tag, product SKU, date, applied discounts, etc.). For the rule to run, the system will verify that all conditions are met simultaneously.

In the Merchant Dashboard. Path: Settings → Returns Policy → Conditional Rules

The Policy Rules Editor (Conditional Rules) is the operational brain of your returns portal. It allows you to move from a rigid policy to an intelligent system that automatically adapts to each customer, product, and purchase context.

On the home page you can view, organize and audit all your active and inactive rules.

1. Key Concepts

• Action (The "What"): The effect the rule will have (e.g., charge an extra fee or block a change).

Important: There can only be one action per rule .

• Conditions (The "When"): The requirements that must be met. You can combine multiple filters.

The rule will only be triggered if all conditions are met simultaneously ( AND logic ).

• Priority (The "Order"): The system reads the rules from top to bottom . The order is critical when several rules affect the same order.

3. Rules Information

On the main dashboard, each piece of information has a specific operational purpose:

2. Rapid management actions

To the right of each rule, you'll find the options menu to keep your operations up to date:

• Edit: Access the full settings to adjust conditions or actions.
• Duplicate: The fastest way to create similar rules (e.g., replicate a "Silk" rule for "Linen") without starting from scratch.
• Delete: Permanently removes the rule from the system.
• Reorder (Drag & Drop): Click and drag the rules to change their execution priority.

Setting up a rule is a logical and sequential process. Here we explain what each step means so you have complete control of your portal:

1. Identification and validity

The first thing is to define the "identity" of your rule.

• Name: Give it a clear title (e.g., "Christmas Campaign - Private Sales" ). This will facilitate quick audits of your listing.

Clear Names: Don't call the rule "Rule 1". Use names like "Christmas Campaign - Extended Window".

• Description: A space to explain the "why" behind the rule. It helps other members of your team understand the logic without having to edit it.

Use the Description: Explain why the rule was created. This will help your support colleagues understand the logic months later.

• Validity period: You can schedule when a rule starts and ends. Ideal for automating sale periods or temporary promotions without having to manually activate them.

Use the Validity Period for campaigns like Black Friday or Christmas. You can set up the rules today and they will automatically activate when the date arrives, giving you complete peace of mind.

2. Definition of the Action (The "What")

Here you decide the effect the rule will have. This is the benefit or restriction that will be applied to the customer. You can only choose one action per rule .

Example: "Block returns", "Apply a €5 fee" or "Force refund to Gift Card".

3. Setting Conditions (The "When")

This is the segmentation engine. Here you set the filters that the order must meet for the action to be triggered. You can add multiple conditions, and all of them must be met (AND logic ) .

If the condition is "Country: Spain" + "Label: VIP", the rule will only work for Spanish customers who are also VIP.

4. Status Switch (On/Off)

Each rule has its own independent switch . This allows you to pause a logic (for example, a "Transportation Strike" rule) and reactivate it later without having to delete and configure it again from scratch.

5. Prioritization and Order

The system evaluates the rules from top to bottom .

• If an order meets multiple rules, they will be applied in the order they appear on your list.
• You can drag and drop the rules to change their position. This is vital to avoid conflicts; make sure to put the most specific or restrictive rules at the top of the list.

Order matters: If you have a rule that blocks transfers and another below that forces them, the one above will be evaluated first and will limit the options of the one below.

The Action is the core of your rule: it defines the impact it will have on the customer's request. You can only configure one action per rule . Here are the details and when to use them:

1. Block options (Order)

Prevent customers from selecting certain request types for the entire order . If you block all options, the customer will receive an error message when trying to start the process.

• Options: You can select one or more:
  • Block returns.
  • Block variant/size changes.
  • Block changes to other products.
• Example: Do not allow returns on orders from the Outlet section.

2. Block options (Product)

Unlike the previous action, this one only affects the specific products that meet the conditions, allowing the rest of the order to proceed normally. The affected product will appear as "Blocked" on the portal.

• Blocking options: Block returns, variant changes, or exchanges for other products.
• Affected products: Determines the ownership of the products that will be blocked.
• Example: Allowing the return of shoes, but blocking the return of silk trousers for reasons of hygiene or delicacy.

3. Extend the returns/exchanges window

It extends the legal deadline for requesting changes or refunds, exceeding the general policy.

• Extra options:
  • Scope: Return period, exchange period, or both.
  • Mode:
    • Extend until a fixed date (e.g., January 31).
    • Add X number of days to the current term.
• Example: Extend the deadline to 60 days for all purchases made during Black Friday .

4. Put request on hold

The automated workflow is paused. The request is created, but it remains pending manual approval by an agent from the Reveni dashboard.

• Options: Reason (Required). You must write the reason (e.g., "Technical review required"). This text will appear in the transaction alert for your support team.
• Example: If it is a client who belongs to the group of “problem clients”.

5. Apply bonus

Apply logistical benefits to incentivize the customer or reward their loyalty.

• Extra options (You can choose several):
  • Free return (no shipping costs).
  • Free exchange.
  • Refund the shipping costs that the customer paid in the initial purchase.
  • Apply a discount
• Example: Offer free exchange whenever the customer belongs to the VIP segment.

6. Apply additional fee

Add an additional cost to the process for management, cleaning or restocking .

• Extra options:
  • Configuration: Rate name (visible to the customer), amount, and currency.
  • Application method:
    • Apply once per application: You are charged only once for the entire application.
    • Apply once per matching product to be returned: You are charged for each unit that meets the conditions.
• Example: Charge €5 for "cleaning and repackaging" for each returned formal dress.

7. Force refund method

It limits the customer's options by forcing them to choose a specific refund method.

• Extra options:
  • Method selector: Store Credit, Gift Card.
  • Include additional credit: If checked, the extra incentive percentage you have configured for that method in the general settings will be applied.
• Example: For discounted orders, only allow refunds to Gift Cards, without including additional credit .

8. Disable refund methods

The opposite of the above: it allows you to disable specific methods that you don't want to offer in certain cases, ignoring the general configuration.

• Additional options: List of methods to disable (Bank transfer, Gift card, Store credit, Original payment method).
• Example: Disable Bank Transfer for international orders due to high fees.

Summary table of actions:

For the action to be triggered, the system analyzes the order properties. Depending on the property, you can choose a different Match Type :

1. Types of Conditions

• Order: Number, date, region, state, type, tags, or if it has discounts.
• Customer: Email, group or customer tags (Shopify/ecommerce tags).
• Request: If the customer is requesting a refund, exchange, or both.
• Product in order: See all products that were originally purchased.
• Product to return: Only see the products that the customer has selected to return.

2. Properties of the conditions

To make a rule hyper-specific, you can choose from the following properties depending on the condition category:

Order (Order Properties)

• Order number: The unique identifier of the order.
• Order date: The date on which the transaction was carried out.
• Order region: Geographic location (country, province or area).
• Order status: Current status on the platform (e.g., paid, shipped).
• Order type: Classification of order type: Initial order, exchange order.
• Order tag: Specific tags imported from Shopify or other platforms.
• Has discounts applied?: Binary field (Yes/No) to detect if there were discounts.
• Discount applied: Allows you to filter by a specific discount code or promotion.

Customer (Customer Properties)

• Customer email: To apply rules to specific users or corporate domains.
• Customer tag: Segmentation tags (e.g., VIP , Recurrente , Fraud_Risk ).
• Customer group: Logical groupings of customers defined in the ecommerce.

Request (Request Properties)

• Request type: Filters according to whether the intention is a return , a change , or a mixed request.
• Has upsells?: Detects if the customer has accepted any upsell offers for a higher-value product during the process.

Product in order (Properties of the purchased product)

• Product name / ID / SKU: Basic product identifiers.
• Product URL slug: Based on the product's web address (e.g. /vestidos-seda ).
• Product type / Product category: Catalog classification.
• Collection: Based on the collection it belongs to (e.g., Rebajas de Verano ).
• Product tag / Product variant tag: Labels at the product or variant level (size/color).
• Custom attributes: Custom attributes defined by the merchant (Metafields).

Products to return (Properties of the Product to be Returned)

• Product name: Name of the selected item (e.g., "Red Silk Dress").
• Product ID: Unique technical identifier of the product.
• SKU: Warehouse reference to identify exact variants.
• Product URL slug: The identifier of the product URL (e.g., pantalones-lino-verano ). Very useful if the merchant organizes their website into logical folders.
• Product type: The class of product (e.g., Calzado , Accesorios ).
• Product category: Hierarchical category within the catalog.
• Collection: The collection to which it belongs (e.g., Outlet , New Arrival , Last Chance ).
• Product tag / Product variant tag: Specific labels that the merchant uses to mark products (e.g., Higiene , No-Refund , Fragile ).
• Custom attributes: Any custom key-value pair (Metafields) that comes from the ecommerce platform (Shopify, etc.).

You can combine properties from different conditions. For example, you can create a rule that only applies if the Order region is "Europe" AND the Customer tag is "VIP".

3. Match types of the properties

The Match Type determines the filter's precision. Depending on the selected property (text, date, region, or logic), the system will offer the following options:

Match Types

1. For Text and Alphanumeric Values

Ideal for product names, SKUs, customer labels, or order numbers.

• Is / Is not: Exact match of value.
• Is any of / Is not any of: Allows multiple values to be entered; the rule is activated if the data matches any of the list (or none).
• Starts with / Doesn't start with: Filters based on the beginning of the text (very useful for SKU prefixes).
• Ends with / Doesn't end with: Filters based on the end of the text.
• Greater than / Lower than: For numerical comparisons (e.g., orders with an order number greater than X).
• Contains / Doesn't contain: Search for a keyword anywhere in the text.
• Contains any of / Doesn't contain any of: Check if the text includes any of the keywords from your list.

In text fields, you can activate the "Case sensitive" checkbox if you need the system to strictly distinguish between uppercase and lowercase letters.

2. For Dates

It is activated when selecting properties such as "Order date".

• Older than: The order is older than X days.
• Newer than: The order was placed less than X days ago.
• In date range / Not in date range: The order is (or is not) between two specific calendar dates.

3. For Geographic Regions

• Among regions in list: The order location matches the countries or provinces selected in the dropdown menu.
• Not among regions in list: Excludes the selected locations.

4. For Logic:

It is activated in confirmation fields such as "Has upsells?" or "Has discounts applied?".

• Yes/No: A binary validation. Whether the event occurred ( Yes ) or not ( No ).

4. Functioning: Property, Match Type and Value

Setting up a rule is like constructing a logical sentence. Each element is essential for the system to know exactly who to filter. The following example illustrates this:

1. Property

It's the data point that Reveni will monitor. It's the "subject" of your rule.

• Order tag has been selected.
• The system will search for the labels that have that specific order.

2. Match type

It is the logical operator that defines the relationship between the property and the result you are looking for. It is the "verb" or the action of comparison.

• Is has been selected.
• The system is looking for an exact match. If you choose Contains , it will be more flexible; if you choose Is not , it will be an exclusion.

3. Value

It's the specific piece of information you're hoping to find. It's the "item" that completes the sentence.

• Example: If you write BlackFriday , the condition is read as: "If the order label is exactly BlackFriday" .
• This field is where you write the text, ID, or select the option that will trigger the rule.

1. Add multiple conditions

At the bottom of the image, you will see the category buttons ( Order , Customer , Request , etc.).

• Clicking on any of them adds a new condition row .
• AND logic: When adding more than one row, the system understands that ALL (Condition A + Condition B) must be met for the rule to work. If one fails, the action is not executed.

2. Character precision (Case sensitivity)

Below the value, you will see a critical box: "Match uppercase and lowercase letters" .

• If NOT checked (default): The system is flexible. It will understand that VIP , vip , and Vip are the same. This is ideal for avoiding human error when writing labels.
• If it's checked: The system becomes strict. If you type VIP and the order has the label vip (lowercase), the rule will NOT be activated . Use it only when you need absolute technical precision.

3. Priority and Order of Evaluation

The rules are read from top to bottom . This is vital because the effects are cumulative .

If Rule 1 disables bank transfer and Rule 2 requires the use of a Gift Card, the final result for the customer will only be the Gift Card.

Place the most specific or restrictive rules at the top to ensure they are evaluated first.

1. Basic level rules

• Special Logistics (Delicate Products)
  • Action: Apply extra fee (per matching product) → €10.00 .
  • Conditions: Product to Return: Category → Contains "Ceramic" or "Glass".
  • Result: A surcharge of €10 is automatically added for each fragile item selected to cover special transport insurance.

• Cleaning Fee (Delicate Textiles)
  • Action: Apply extra fee (once per request) → €5.00 .
  • Conditions: Product to Return: Name → Contains "Silk".
  • Result: A fixed surcharge is charged for the professional management and cleaning required to replenish the product to inventory.

• Premium Return Window
  • Action: Extend Window → +15 additional days .
  • Conditions: Customer: Tag → Is "VIP".
  • Result: Your most loyal customers enjoy an extended term, improving their brand experience without affecting other users.

• Free Exchanges (Incentive)
  • Action: Apply Bonus → Free Exchange .
  • Conditions: Customer: Group → Is "Loyalty Program".
  • Result: If the customer attempts to make a change, the system eliminates logistics costs as a benefit of belonging to the program.

2. Intermediate level rules (2 conditions)

• Refunds on Sale Items (Credit Only)
  • Action: Force refund method → Store Credit .
  • Conditions: * Order: Has discounts → Yes .
  • Customer: Tag → Is not "VIP".
  • Result: Customers who purchased at a discount can only receive store credit, protecting cash flow, unless they are VIP customers.

• Fraud Control / Blacklists
  • Action: Put request On Hold .
  • Conditions:
    • Customer: Email → **Ends with “(**blacklist domains)”.
    • Request: Type → Is "Return".
  • Result: The request does not automatically generate the label; the support team must validate it before the process moves forward.

• Verification of Defective Product
  • Action: Put request On Hold .
  • Conditions:
    • Order: Tag → Is "High_Value".
    • Request: Type → Is "Return".
  • Result: High-value orders are systematically paused so the team can verify the product's condition before issuing a refund.

3. High-level rules

How to use the policy rules editor

Extend Black Friday Return Window

High Value Product Verification