Skip to content

Formulas

Formula tester

In Lime admin there's a Formula tester where you can run a formula and get the result. This is a good way of learning and testing functionality.

Go to: Lime Admin => Settings => Standard Actons

You input:

  • Expected output type (Required)
  • Context:
    • Limetype (Required)
    • Id (Optional)
  • Property (Optional) - If expected output type is auto, use this property to cast to correct type

Then write your formula and press Generate value

Below you see an example of a simple formula

Example of a formula

Jinja syntax

The formula has to follow the syntax rules of Jinja to be rendered correctly. Please checkout their documentation for a complete feature overview. This section will go through some common use cases for formulas and show examples for how to solve those with Jinja.

Merge code variables

Starting from the given context lime object you can use all its properties as well as nested properties on related limetypes.

Here are a few valid examples from the deal limetype:

  • {{ name }}
  • {{ person.name }}
  • {{ person.company.name }}
  • {{ person.company }}

Setting relations

Merge codes that end on a relation field (like {{ person.company }}) will render the limetype's descriptive. If you want to set the relation you will need to use {{ person.company.id}}

The limeobjects descriptive field is also accessible using .descriptive in the of your formula.

Pre-defined merge codes

A set of pre-defined merge codes are available when using formulas. These merge codes are available from the merge code variable context.

Available pre-defined merge codes
  • context.today - returns a date object with the current date, excluding time (2021-10-27 00:00:00).
  • context.now - returns a date object with the current timestamp, including timezone (2021-10-27 15:42:50 + 02:00).
  • context.active_user - returns the coworker object of the user generating the document.

Formatting

Variables can be rendered in a specific format by adding a filter. Filters are used within a variable, separated by a pipe (|) character like this: {{ <merge>.<code> | <filter> }}. Check out this list of built-in Jinja filters.

One very handy example of this is the sum filter. {{ deal.orderitems | sum(attribute='price') }} will sum up the price of all order items in a deal.

Date and time

Filters for formatting and manipulating dates and time are included. Further information and examples can be found here.

Numbers

Filters for formatting numbers are included. Further information and examples can be found here.

Lists

Whether you want to show all order items in an offering or list achievements in a certificate, there are a lot of use case where the possibility to loop through a list is needed. An example would be:

{% for orderitem in deal.orderitems %}
{{ orderitem.name }}: {{ orderitem.price }} {{ orderitem.currency }}
{% endfor %}

You can also find the example in the linked Word document example.

For more build-in list functionality read this section in the Jinja documentation.

Conditional expressions

Does your formula have a paragraph that should only be included under certain circumstances? For instance some extra information that only prospects need?

{% if deal.company.buyingstatus == 'prospect' %}
This is a paragraph about how amazing your company is.
Existing customers already know that.
{% endif %}

Option and Set Properties

Option and set properties work a little differently than other fields because their values have labels with translations. Option and set fields define keys and labels for each key. In the web and desktop client, when a specific key is selected for an option or set field, the correct label is shown to the user depending on their language.

The below examples assume:

  • A template with en_US locale
  • A company option field buyingstatus with the key notinterested and the labels Not interested for english and Ointressant for swedish,
  • A person set field allergies with the keys vegetarian and lactose with english labels Vegetarian and Lactose respectively.

By default in document templates, option and set fields will just render their key(s).

{{ deal.company.buyingstatus }}
notinterested

{{ deal.person.allergies }}
vegetarian, lactose

To render a label, you must use the localize filter. The below will render the label for the templates configured locale (for sv_SE it would render Ointressant). If there is no label for the template locale, it falls back to the default language of the application.

{{ deal.company.buyingstatus | localize }}
Not interested

{{ deal.person.allergies | localize }}
Vegetarian, Lactose

You can override the template locale on a case by case basis as well

{{ deal.company.buyingstatus | localize(locale="sv_SE") }}
Ointressant

Set properties have some additional use cases

{% for allergy in deal.person.allergies %}
- {{ allergy | localize }}
{% endfor %}

{% if "lactose" in deal.person.allergies %}
Below is a list of lactose free alternatives you may request

- Soy milk
...
{% endif %}

Info

Although locale (which contains a language code such as sv and a country code such as SE) is used for getting the label for set and option fields, the CRM only stores a label for each language, so the country part of the locale will have no affect on the rendering of the field.