Display conditions

Display Conditions has moved to our new BEE Plugin docs site. Please note that this feature is available on BEE Plugin paid plans (Silver plan and above)

Conditional statements, easy and fast

Display conditions is a fantastic new feature that allows for conditional statements in email messages or landing pages created with BEE, easy and fast, like all things in the BEE editor!


Your users will have the ability to pick a condition (or write one from scratch if they are technically savvy), apply it to a row, and thus show different content based on who the recipient (or viewer) is.

For example, there could be a row that contains information that will only be shown if the recipient of the email is a current user of a certain product, and will not be hidden if the condition is false.

The condition "is this a current user?" is something that your application will have to look up. BEE has no way to know whether it's true or not. BEE simply allows users of the editor to apply that conditional statement to a row of content so that later - at the time of sending the email or rendering the landing page - your application can parse the HTML, find the conditional statement, and act on it.


How Display conditions are shown in the editor

Once the feature has been activated server-side in the application configurations, you can pass an array of display conditions to BEE Plugin when you initialize the editor, as part of the editor's configuration. The array of conditions will be described as a JSON document with each node being defined by 5 properties:

  1. type: allows you to group conditions, making it easier for users to navigate them
  2. label: the name of the display condition
  3. description: a short description that tells the user what condition will be applied
  4. before: the syntax that will be added to the HTML source code before the selected row
  5. after: the syntax that will be added to the HTML source code after the selected row

For example...

      var rowDisplayConditions = [{
        type: 'Last ordered catalog',
        label: 'Women',
        description: 'Only people whose last ordered item is part of the Women catalog will see this',
        before: '{% if lastOrder.catalog == \'Women\' %}',
        after: '{% endif %}',
      }, {
        type: 'Last ordered catalog',
        label: 'Men',
        description: 'Only people whose last ordered item is part of the Men catalog will see this',
        before: '{% if lastOrder.catalog == \'Men\' %}',
        after: '{% endif %}',
      }, {
        type: 'Last ordered catalog',
        label: 'Children',
        description: 'Only people whose last ordered item is part of the Children catalog will see this',
        before: '{% if lastOrder.catalog == \'Children\' %}',
        after: '{% endif %}',
      }, {

Those conditions become available for users of the editor to select, assuming the feature is turned ON and the user has permissions to apply a condition to a row. 

They will do so by browsing through categories or searching by keyword. For example...


The condition that they pick is applied to the row and displayed when the row is selected.


It can be changed (i.e. the user decides to apply another condition) or edited (if the user has the technical skills to do so, and its user role has been granted those permissions).


When the Preview feature is accessed, users can now simulate what recipients in a certain segment will see by toggling Display conditions on and off.



Benefits of adding content personalization with display conditions

Display conditions allow you to change the content that is shown to recipient of an email depending on who the recipient is. The feature provides a number of benefits, including...

Ease of use for email designers

Display conditions allow anyone that is building an email with the BEE editor to easily build personalized messages without writing a line of code.

Any syntax for the conditional statements

Use whatever syntax your application understands. The feature is language agnostic: it can be used with whatever syntax matches your tech stack. Does your sending engine understand the Liquid markup? Then you can use Liquid. Does it use  a proprietary templating language? No problem.

User permissions

Restrict access to some of the functionality based on user roles. For example, some users may be able to edit the syntax of the conditional statements, while others may not. Use this flexibility to simplify the UI or promote upselling.


Display conditions and user roles & permissions

When active, the feature is available to all users by default. You can manage who can see and/or do what by leveraging user roles and permissions.

When the feature is ON, new permissions are available for you to configure when you create or edit a Role.


A basic set up allows you to have 3 user levels:

  1. Can only view & preview
    1. None of the above options are selected
    2. No widget will be shown unless the loaded message has display conditions assigned to one or more rows
    3. If conditions are applied:
      1. They are shown as ready-only
      2. They can be applied in the Preview
  2. Can only select
    1. Only Can select conditions option is selected in the role settings (remove will be automatically selected too)
    2. The widget shows and the user can select and apply any of the conditions specified in the editor configuration
    3. The user cannot add a new condition
    4. The user cannot edit a selected condition
  3. Full control
    1. All permissions are selected
    2. The user can select and edit conditions (if provided) or add a new condition

Note: if there are no Display conditions passed to the Plugin in the configuration, and the user has the rights to access the feature, the editor will only show the Add condition action, which allows users to apply a new condition to a row by manually adding the condition's syntax.


More information

Identifying a row with an applied display condition

It's easy to identify a row to which a display condition has been applied. A bifurcation icon is added to the row's "Structure" tag, which is shown as you mouse over the row. Here's an example:



Custom conditions

When a default Display condition is edited - by a user that has permissions to do so - it becomes a custom condition. Custom conditions are easy to recognize because:

  1. A blue dot is added next to the condition's name
  2. The "Change condition" button is no longer available: a custom condition can only be removed
  3. The cancel icon is replaced by a trash button because an edited condition, once remove, is lost: it cannot be re-added.


Why these different behaviors for custom conditions? Because BEE does not save them to the Plugin configuration (you passed that configuration to the Plugin: we don't have access to the repository where you save that information). So, custom conditions do not exist in the array of conditions that the user can search and/or browse.


HTML output

Conditional syntax and row content are isolated from each other in the HTML generated by BEE, so your system can delete, repeat or change elements inside the row without impacting other parts of the message. For example, the HTML of a row might look like this...



Frequently asked questions about Display conditions

What if the feature is turned OFF in the server-side settings?

If Display conditions is turned OFF in your application's server-side settings, then the editor will behave exactly as it did when this feature did not exist.

Can the image and text displayed be dynamic?

Sure, it's entirely up to you what the content in the row is. So you can certainly use merge tags and dynamic images.

What syntax/characters can be used in the conditional statements?

BEE is agnostic to the language used in the conditional statements. The editor will simply add the syntax that you provide before and after the selected row in the HTML document that it will generate when the message is saved. The editor will not perform any validation on the provided syntax.


Activating the feature

Please note that the Display conditions are disabled by default. You can turn this feature on by enabling it under the Server-side configurations. You must be on a BEE Plugin paid plan (Silver subscription and above) to enable this feature.


Have more questions? Submit a request


  • Avatar
    Karel Antonio Verdecia Ortiz

    Hi, in what parameter can I pass the conditions config to the beefree plugin?

  • Avatar
    Massimo Arrigoni

    You need to pass the conditions to the Plugin by including them in the BEE Plugin configuration.

    The array of display conditions should be described as a JSON document. See the example towards the top of the page.

    For more on configuring the editor, please see: https://support.beefree.io/hc/en-us/articles/360004495552-Configuring-the-editor

  • Avatar
    mayur sorathiya

    selected User access to drag and drop.
    Still show the drag and drop but once they try to click it it will show this message "You can Not Able to access this functionality"

    How to Implement this functionality

  • Avatar
    Massimo Arrigoni

    Hi Mayur, if we understand your request correctly, you would like to use "User roles and permissions" (https://support.beefree.io/hc/en-us/articles/360004495712-How-to-configure-user-roles-and-permissions) to allow someone to drag and drop a content element into the editor, but without being able to edit it. That is unfortunately not something that is supported at this time. Could you clarify the scenario?