Dynamic Variables

Maptaskr provides a set of dynamic variables that you can leverage within configuration panels and custom settings. These variables enable flexible, context-aware configurations by allowing values to be dynamically populated based on the current user, environment, or map context. When the map control is initialized, dynamic variables allow you to access both map data and surrounding form data, making it easy to create adaptable configurations that respond to the current context. This page lists all available variables, describes their purpose, and provides example usage to help you get the most out of Maptaskr's customization capabilities.

Where Can You Use Dynamic Variables?

You can use dynamic variables in various places, including:

Usage Area	Description
Layer Filters	Apply a dynamic layer filter in a predefined layer based on form data.
Layer Actions	Customize how map layers behave based on form or user data.
Map Actions	Trigger map events or workflows using contextual information.

Available Variables

When the map loads, Maptaskr Power Maps automatically retrieves all form fields rendered within the form. In addition, it captures key context information such as the application ID, page type, and the ID of the open record from URL parameters. These variables are available for use in your configurations.

Commonly Available Variables

Variable Name	Description	Example Value
{{foo}}	PCF Fields added to the "AdditionalParameters" Textbox will appear as variables in your filters.	bar
{{appid}}	The unique identifier of the current application.	f3e94f42-33c1-427a-8de4-d89195f613ba
{{pagetype}}	The type of page currently open (e.g., entity, dashboard).	dashboard
{{id}}	The ID of the open record (or dashboard) from the URL.	67e9280b-b8ab-431c-a07a-ba6b3407f421
{{userId}}	The unique identifier (GUID) of the current user.	acf84355-08b7-4e07-aa21-fc015192e962
{{userName}}	The full name of the current user.	John Smith
{{userLanguage}}	The Language Code for the current users profile.	1033
{{userRoles}}	The security roles assigned to the current user.	d2b9f074-d25e-4a8e-8d68-d5106443fe5f, 7dd5eb36-e3fa-4d14-b4fa-67e5fff1065c, 43bf58c9-e2f9-431e-aed3-12f5fe399ea9

Attribute Variables

These variables are derived from the attributes of the current selected feature and also include some special fields.

Variable Name	Description	Example Value
{{maptaskr_lat}}	The centroid latitude value from the selected feature	-33.868123456
{{maptaskr_lng}}	The centroid longitude value from the selected feature	151.209123456
{{maptaskr_geometry}}	The geometry (e.g., GeoJSON) of the selected feature	{"type":"FeatureCollection","features":[{"type":"Feature","properties":{},"geometry":{"coordinates":[115.82150874385223,-31.886554728245706],"type":"Point"}}]}

tip

To use a form field, wrap its logical name in double curly braces, e.g., {{firstname}} or {{accountnumber}}.

Example Usage

Suppose you have list of Sites. On selection on one of those sites you want to filter a layer called assets based on the current records id. You could use:

Field	Comparison	Value
Site Id	Equals	{{id}}

• Site id is a field that sits with in the attributes list of the layer
• {{id}} is the variable pulled from the url which refers to selected record

Or, when calling an action such as OpenD365Modal that is designed to edit a record

EntityName	entityId	formProps
account	{{accountid}}	latitude: {{maptaskr_lat}} longitude:{{maptaskr_lng}}

Advanced Dynamics Variables with LOOKUP

You can enhance your filters by leveraging the powerful LOOKUP function. This allows fields such as filter values and formProps values to dynamically retrieve data from a Dataverse table based on a form variable, returning a specific value from that table.

For example:

{{LOOKUP('{{dynamic_value}}','logical_entity_name','entity_column','return_value')}}

How the LOOKUP function works:

Parameter	Description
LOOKUP	The function name.
'{{dynamic_value}}'	The value to search for, typically from the layer's attribute list Remember {{dynamic_value}} is a dynamic value.
'logical_entity_name'	The name of the Dataverse entity (table) to search in.
'entity_column'	The column within the entity where the function will look for the OBJECTID value.
'return_value'	The column from which to return the value once a match is found.

This approach enables you to create highly dynamic and context-aware filters, ensuring your map configurations are both flexible and powerful.

Best Practices

• Always verify the variable name matches the logical name of the field in your environment.
• Use variables to make your configurations reusable and adaptable across different forms and users.
• Test your configurations to ensure variables resolve as expected in your scenarios.

For a full list of available variables in your environment, inspect the form fields or consult your system administrator.

Example: Pre-populating a Dynamics Email form (OpenD365Modal)

Scenario

You want to open a Dynamics 365 Email form and automatically:

• Populate the Email form's To lookup with the Primary Contact(s) of the selected Account feature(s)
• Set the Subject to the Account name(s)

Why this lives here

This example demonstrates practical usage inside a Layer Action definition. If more examples accumulate, we may move them to a dedicated "Action Recipes" page and link back here. For now, it stays inline as a concrete, high‑value illustration.

Pattern basics

Single selection (conceptual structure of a lookup array):

[ { entityType: account, id: {{accountid}}, name: {{name}} } ]

Multi‑selection pattern (the |, tells the engine: repeat per selected feature and join with commas):

[ {{ { entityType: account, id: {{accountid}}, name: {{name}} } |, }} ]

---

Suppose our Accounts layer exposes these attributes:

• accountid
• name (primary name / Account Name)
• primarycontactid (lookup to Contact)

It does not expose the Contact's full name.

Goal: Build action data so that:

• The Email form To lookup contains Contact records (ID + resolved display name)
• The Subject contains the Account name(s)

If the contact's name were already exposed (e.g. contactname), we could do:

Single selection (field → value):

to = [ { entityType: contact, id: {{primarycontactid}}, name: {{contactname}} } ]
subject = {{name}}

Multi‑selection:

to      = [ {{ { entityType: contact, id: {{primarycontactid}}, name: {{contactname}} } |, }} ]
subject = {{name|,}}

However, the contact's display name is NOT available directly, so we use the LOOKUP function (see more in Variables).

Using LOOKUP to resolve the Contact fullname

We want the Contact's fullname given primarycontactid.

Single selection with lookup:

to      = [ { entityType: contact, id: {{primarycontactid}}, name: {{LOOKUP('{{primarycontactid}}','contact','contactid','fullname')}} } ]
subject = {{name}}

Multi‑selection with lookup:

to      = [ {{ { entityType: contact, id: {{primarycontactid}}, name: {{LOOKUP('{{primarycontactid}}','contact','contactid','fullname')}} } |, }} ]
subject = {{name|,}}

Expression:

{{LOOKUP('{{primarycontactid}}','contact','contactid','fullname')}}

Parameter	Meaning
LOOKUP	Function name.
'{{primarycontactid}}'	Contact GUID already present on the Account feature.
'contact'	Target Dataverse table.
'contactid'	Column in contact table matched against the supplied GUID.
'fullname'	Column whose value is returned when a match is found.

Result: You can populate a Dynamics lookup with both the ID and a resolved display name even when only the GUID was originally available on the feature.