Custom parameters let a query accept a value from outside the query and use that value in filters or formulas. They are commonly used in web services, portals, reports, embedded dataset row queries, and other contexts where a query should return data for a specific record, URL value, or user selection.
A custom parameter has two parts:
The parameter declaration, written as a
<param>XML element in the query settings.The parameter reference, written with an at sign in the query, such as
@recordor@major.
Understanding custom parameters
A custom parameter creates a named placeholder that the query can use when it runs. The value is not stored in the query. Instead, the value is supplied by the context that runs the query.
For example, an embedded dataset row query can receive the GUID of the dataset record currently being viewed. The query can then use that value in a GUID filter so the embedded query returns only rows related to that record.
Custom parameters are also used when:
A portal method passes a selected record ID into a detail query or pop-up query.
A portal search page passes selected filter values into a search query.
A web service receives values through query string parameters.
A rendered report URL passes values into report filters.
Adding a custom parameter
Add custom parameters in the query or report setting that accepts parameter declarations. The exact label varies by context. For example, a query used as a web service uses Edit Web Service, while a portal method query commonly uses Edit Parameters.
Open the query, portal method query, report, or embedded query that should receive a parameter value.
Open the relevant parameter editor, such as Edit Web Service or Edit Parameters.
In the parameters field, enter one
<param>element for each value the query should receive.Select Save.
The following example declares a parameter named record that expects a GUID value:
<param id="record" type="uniqueidentifier" />The following example declares two portal search parameters that both receive text values:
<param id="major" type="varchar" />
<param id="region" type="varchar" />Using a parameter in a filter or formula
After you declare a parameter, reference it in the query by adding @ before the parameter ID.
For example, if the parameter is declared as record, use @record in the filter or formula that should receive the value.
Add or edit the filter, formula, or subquery formula that should use the parameter.
Enter the parameter reference where the filter or formula expects the value.
Select Save.
For a GUID filter, the value might be entered as:
@recordFor a formula, the value might be tested before applying a filter condition:
((@major is null) or (@major_guid = @major))Passing a value to the query
The parameter declaration only tells the query which values it can receive. Another part of Slate must still supply the value when the query runs.
In an embedded dataset row query, the surrounding dataset record can pass its record GUID into the query. These queries often use a parameter such as record with a uniqueidentifier type.
The portal method, portal URL, or portal view can pass values into linked queries. The query can then use those values in filters or formulas.
The portal view can pass selected search values into the results query. Each filter usually needs a matching parameter in the search query.
The request URL can include query string parameters. The query can use those values in filters or formulas.
The rendered report URL can include parameter values. The report can use those values in part filters, column filters, or row group filters.
For a web service or report URL, a parameter named term might be passed as a query string value:
https://example.edu/manage/query/run?id=QUERY_GUID&term=2026Choosing parameter names and types
Use a parameter ID that describes the value being passed. Common examples include record, person, application, term, major, and region.
Common parameter types include:
uniqueidentifierfor GUID values.varcharfor text values.dateordatetimefor date values.intorrealfor numeric values.bitfor true or false values.
Some documented procedures use context-specific parameter types, such as record or string. When a feature-specific article provides a required type, use the type shown in that article.
📝 Note
Some contexts use special or reserved parameter names. For example, web service endpoints use parameters such as
id,h, andoutput. Use the parameter names shown in the article for the feature you are configuring, especially when a documented pattern intentionally uses a contextual value such asidorrecord.
Testing custom parameters
A query that depends on a parameter may return no rows in preview until you supply a test value. To test the query, run it from a page that lets you enter parameter values, or open the context that normally passes the value into the query.
For example, when testing an embedded dataset row query that uses @record, enter the GUID of a dataset record before running the query. When testing a portal pop-up query, confirm that the value in the URL uses the same parameter ID that the query declares.