Skip to main content
Tags, Parameters, & Forms

Learn how to tag values and transform your SEL expressions into forms.

Updated over 5 months ago

What are Tags?

Though we use functions within SEL models, as far as the outside world is concerned, SEL models themselves are essentially functions. Since functions are more powerful when they can take input values (arguments), SEL provides modelers with a way to specify arguments. In SEL, we call these tags.

Tags are a way to specify arguments in Summit Event Language (SEL) and help clarify assumptions about your model and logic to yourself and other readers.

You can define a tag in a SEL expression by entering text between two brackets, < and >, like so:

=100<users>

If the event is titled "New Customers", the tag is helpful for clarifying that the 100 refers to 100 users, and not 100 accounts or contracts.

Tags can be placed after any constants, inside or outside of lists and function calls. For example:

=Source(1.5k<opportunities> @ 2%)

πŸ’‘ Notes:

  • Tags should always be lowercase and should not contain spaces or numbers.

  • An underscore _ can be used to separate individual words, e.g. <growth_rate>.

  • Other special characters such as . , ! % : - & # @ should not be used in tags.

  • When applying tags to growth rates on SEL functions such as Source and Pool, ensure the tag is placed between the value and the % symbol to avoid errors, like so: =Source(10k<mrr> @ 5<growth_rate>%)

What are Parameters?

In addition to acting as convenient labels in SEL, tags have another special purpose: to define input Parameters! Parameters are used to create the input fields in the app view of app view of a model.

Using the example =Source(1.5k<opportunities>), <opportunities> is the tag and opportunities is now a parameter in the model.

A parameter is powerful because it allows you to update multiple values at once across one or multiple SEL expressions. For example,

=Pool(100<credits> + (1.2<multiplier> * 100<credits>))

In this case, changing the value of credits to 200 will replace both of the 100s with 200.

πŸ’‘ Note on Parameter formatting: As a best practice, a parameter should be written lowercase_without_spaces_or_symbols. For example: metric_tons. While Metric Tons would also work, spaces and capitalization add additional complexity that can make your model more difficult to work with as it becomes more advanced.

Formatting Parameters & Using Aliases

When a tag is converted to an input field, by default, the Summit Editor will convert the tag to Title Case for the form label on the event, like so:

  • users β†’ Users

  • metric_tons β†’ Metric Tons

  • cash_balance_usd β†’ Cash Balance Usd

As you can see, this isn't always ideal, because USD should be capitalized in full instead of Usd. We can fix this using an Alias. An alias appears in a tag after the parameter and a : colon, like so:

=Pool(100k<cash_balance_usd:Cash Balance USD>)

In this example, the form label will now be Cash Balance USD.

This gives you the freedom and flexibility to have the label appear differently than the parameter name, or to overwrite the automatic change to Title Case by default.

πŸ”” Note: Unlike tags and parameters, aliases can contain spaces, special characters, numbers, and uppercase letters.

Aliases also allow you to make it clear that the same parameter used in different places has different meanings. For example:

=Pool(100k<amount:Savings>)

=100k<amount:Savings Portion> + 30k

In this case, the SEL author wants the 100k value to use the same parameter, but to communicate that this value has different meanings depending on where it appears. Aliases allow the author to express this distinction by making sure the label on the event form appears differently on each event.


Did this answer your question?