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.
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 100
s 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.
Keep Reading: Preview & Configure Your App