Dynamic content & tokens — reference
All editionsWherever a box in the configuration accepts a value that is worked out when the form runs, DFFS can insert a token for you rather than making you remember its syntax. This is every entry that menu offers, and the exact token each one writes.
Where these work — and where they do not
Tokens are resolved by DFFS in the inputs where the Add dynamic content menu appears: rule action values, HTML and rich-text blocks, email subjects and bodies, placeholders, validation messages, and similar configuration boxes. The menu showing up is the reliable signal that tokens are supported there.
They are not a general-purpose templating language. Putting [[currentuser:email]] in Custom JS does nothing — it is just a string in your code, and nothing substitutes it. Read values there with getFieldValue() and the rest of the Window API instead.
Using the menu
Click into the box first. The Add dynamic content link only appears while an input has focus, which is why it is easy to work with DFFS for a long time without noticing it. Once open, choose a category, then the value you want — it is written into the box at the cursor, so you can mix tokens with ordinary text.
It is worth using even when you know the syntax. A mistyped token raises no error — it resolves to nothing, so the symptom is an empty value with nothing to explain it. The menu also writes column internal names, which is where hand-written tokens most often go wrong, and it fills in the JSON payload the timestamp tokens carry.
Field value
The first entry lists the columns on the list. Picking one inserts [[fieldValue:InternalName]]. Some column types offer extra variants underneath, because one stored value can be read more than one way.
| Column type | Menu entry | Inserts |
|---|---|---|
| Any | the column itself | [[fieldValue:InternalName]] |
| Date / Date & Time | Dateobject | [[fieldValue:X.dateObject]] |
| Datestring | [[fieldValue:X.dateString]] | |
| Formatted datestring | [[fieldValue:X.formattedDate:MM/dd/yyyy]] | |
| Dateobject with offset (plus or minus days) | [[dateFieldOffset:fieldValue:X:{"offsetDays":0,"time":"08:00"}]] | |
| Lookup | ID | [[fieldValue:X.LookupId]] |
| Value | [[fieldValue:X.LookupValue]] | |
| Person or group | id (user id) | [[fieldValue:X.id]] |
| title (display name) | [[fieldValue:X.title]] | |
[[fieldValue:X.email]] | ||
| name (login name) | [[fieldValue:X.name]] | |
| Attachments | List of attachments | [[fieldValue:X.list]] |
X stands for the column’s internal name — not its display name. The two differ more often than people expect, which is the main reason to let the menu write the token rather than typing it.
On person columns the menu entry is the property itself, with a plain-English gloss beside it — name (login name) inserts .name. So the label tells you exactly what ends up in the box.
Current item
Values about the item the form is open on. Several are unavailable in places where there is no item yet.
| Menu entry | Inserts | Available |
|---|---|---|
| List item id | [[item:id]] | Not on a new form — the item has no ID until it is saved |
| Current form / item link | [[item:link]] | Not on a new form |
| View item link | [[item:link_disp]] | Email actions only |
| Edit item link | [[item:link_edit]] | Email actions only |
| Filepath | [[item:filePath]] | Document libraries only |
Current user
Two separate groups, and the difference matters. Current user (info) reads what SharePoint already knows about the signed-in user — it is immediate and always available. Current user (profile) reads the User Profile Service, which carries organizational detail such as department but depends on the profile being populated and synchronised.
| Group | Menu entry | Inserts |
|---|---|---|
| Current user (info) | UserId | [[currentuser:id]] |
| DisplayName | [[currentuser:displayName]] | |
[[currentuser:email]] | ||
| LoginName | [[currentuser:loginName]] | |
| Current user (profile) | AccountName | [[userprofile:AccountName]] |
| Department | [[userprofile:Department]] | |
| WorkEmail | [[userprofile:WorkEmail]] | |
| Other properties from user profile | Any profile property, in the form [[userprofile:PropertyName]] |
SharePoint group members
Expands to the members of a site group. This one is only offered on the To, Cc and Bcc boxes of a Send email action, since that is the only place a list of people is a sensible value.
| Menu entry | Inserts |
|---|---|
| Each site group, by name | [[SPGroupMembers:GroupName]] |
Groups whose membership is visible only to members are flagged in the menu — the token still resolves, but only for users allowed to see that membership.
Site collection and web
| Menu entry | Inserts |
|---|---|
| Site collection absolute URL | [[site:absoluteUrl]] |
| Site collection relative URL | [[site:serverRelativeUrl]] |
| Web absolute URL | [[web:absoluteUrl]] |
| Web relative URL | [[web:serverRelativeUrl]] |
| Web title | [[web:title]] |
In a vLookup child form these describe the web the child form’s own list is on, not the page the form was opened from.
Current list
| Menu entry | Inserts |
|---|---|
| List title | [[list:title]] |
| List ID (GUID) | [[list:id]] |
| List root folder (URL name) | [[list:rootFolder]] |
The GUID is inserted without braces, which is the form the REST API expects — so it can be pasted straight into a filter such as /_api/web/lists/getById('…').
Timestamp
Dates worked out when the form runs. The inserted token carries a small JSON payload you can edit in place — change offsetDays to shift the date, or format to change how it is written.
| Menu entry | Inserts |
|---|---|
| Today’s date (formatted) | [[timestamp:{"date":"today","format":"MM/dd/yyyy"}]] |
| Today’s date (current culture format) | [[timestamp:{"date":"today","format":"locale"}]] |
| Today as date object | [[timestamp:{"date":"today"}]] |
| Specific date as date object | [[timestamp:{"date":"4/22/2025","time":"08:00"}]] |
| Today’s date offset (plus or minus days) formatted | [[timestamp:{"date":"today","offsetDays":0,"format":"MM/dd/yyyy"}]] |
| Today’s date offset (plus or minus days) as date object | [[timestamp:{"date":"today","offsetDays":0,"time":"08:00"}]] |
Use a date object when the value is going into a date field, and a formatted or culture variant when it is going into text a person will read.
URL query string value
Reads a parameter from the URL the form was opened with — useful when a link into the form carries context, such as an origin or a preselected value.
| Menu entry | Inserts | Notes |
|---|---|---|
| Get query string value | [[getUrlKeyValue:key]] | Replace key with the parameter name. |
| Compare query string value | [[compareUrlKeyValue:key=value]] | Returns true or false — intended for a rule condition rather than a value. |
Variable
| Menu entry | Inserts |
|---|---|
| Use a variable | [[variable:NameOfVariable]] |
Variables are also how multi-language labels are handled, so the same token works for MUI text.
If a token does not resolve
A token that DFFS cannot resolve produces an empty value rather than an error message. Three causes account for nearly all of them:
- The spelling is wrong — delete the token and re-insert it from the menu rather than correcting it by hand.
- The internal name is wrong — a column’s internal name is fixed when it is created and does not follow later renames, so Date needed may well be
DateNeededor something less obvious. - The value does not exist yet —
[[item:id]]on a new form is the common case, since the item has no ID until it is saved.