Page Parameters

A page parameter is an arbitrary variable used to pass information into a Skuid page. There are different ways to pass in page parameters depending on the context and use case.

Types of page parameters

Including parameters in a URL is a common way to pass and retrieve information between pages in web development. Similarly, parameters can be passed between Skuid pages using:

  1. Query string parameters
  2. URL merge parameters

Query string parameters

The most commonly used way to pass parameters is by including them in a query string, which is a collection of identifiers and key-value pairs preceded by a question mark. For example:

http://example.com/animals/mammals?felines=lion

In this example, the query string passed to the server, everything that comes after the ?, is a parameter, felines, requesting all records of felines with the value “lion.”

Page parameters act the same way in Skuid: they allow additional information to be passed into a Skuid page.

On Skuid SFX, page parameters are added to query strings by model conditions, actions, and render/enable conditions through the Page/URL Parameter option, and, in some components, in the query string property.

When using page parameters in query string parameters, there are two important rules to keep in mind:

  1. The parameters must always come after a question mark (?), which indicates the beginning of a string of one or more URL parameters.
  2. Every subsequent URL parameter must be prepended with an ampersand (&).

As long as query string parameters are used in this format, they are accessible within a Skuid page.

Note

Passing parameters into query strings is different in Lightning Experience. For more information, see Using Page Parameters In Salesforce Lightning.

URL Merge Parameters

Used on Skuid NLX, page parameters are included within URLs through URL merge parameters. For example, www.example.com/home/{myParameter}.

On Skuid NLX, you can use URL merge parameters in model conditions, actions, render/enable conditions through the Page/URL Parameter option. They can also be used while constructing an app, and the pages within the app, by inserting URL merge parameters in the app and/or the page URLs. They can also be used for creating REST model conditions.

Using Page Parameters

Builders can access page parameters with model conditions, actions, render/enable conditions, and through the Page/URL Parameter option on some Skuid features.

Values are accessible through the {{$Param}} global merge variable.

For example, {{$Param.myRouteParameter}}.

They may also be passed to Page Includes by setting the component’s Query String property to point to this global merge variable.

Using the Go to URL action with URL merge parameters

When creating a link with URL merge parameters in Skuid NLX, the process is similar to that outlined in Build an app navigation bar using the Go to URL action.

The key difference is that you point the URL to a URL merge parameter. This merge parameter could be a context-dependent merge variable or a global merge variable.

For example, the marketing/orders path has a table listing each order, displaying some general information about each order. That table could have a row action that redirects to the following URL:

/marketing/orderdetails/{Id}

This redirect URL sends end users to a new route (/marketing/orderdetails), just like the redirect URLs from the Build an app navigation bar using the Go to URL action topic mentioned above. The key difference is the added URL merge parameter, {Id}, which references the model’s Id field. This means the context will be determined by the row the end user clicks, passing in that row’s Id value when clicked.

So, if the user clicks an order that has an Id of AuXun109274009, Skuid sends the user to the detail page with the row item’s Id in the URL parameter: /marketing/orderdetails/AuXun109274009

The final step is setting a condition on the detail page that looks for the URL merge parameter:

  1. Click the Models tab in the Elements pane.

  2. Click the Orders model.

  3. Add a new condition for the Id field.

  4. Set the Value as follows:

    • Content: Page/URL parameter value
    • Value: Id
  5. Set its condition state to Always On.

With this condition set, this model always looks for the URL parameter named Id for the matching record Id.

Page parameter examples:

  1. myapp.skuid.com/accounts: In this example, no parameters are provided.
  2. myapp.skuid.com/accounts/{accountId}: In this example, when a user visits this URL, Skuid pulls the “accountId” from the requested record and passes it to the URL. If the record’s accountId was AuXun109274009, the URL the user would see is myapp.skuid.com/accounts/AuXun109274009
  3. myapp.skuid.com/accounts/{accountId?}: The addition of the ? makes the parameter accountId optional, so if there wasn’t a value for accountId, the user would be directed to /accounts instead of receive a Page Not Found error.

Note

Unless a parameter is marked optional with ?, end users will see a Page Not Found error if they navigate to that page without the parameter in the URL.

Using Page Parameters In Salesforce Lightning

When working in Lightning experience, builders will often use record Ids to create corresponding record detail pages. The Skuid Page Lightning component can determine the record Id based on the way Lightning structures URLs.

However, if you want to pass in other parameters besides an Id, they must be namespaced and added via query string parameters.

For example, adding the default namespace prefix to the parameter accountId creates c__accountId. Non-namespaced parameters are removed from the URL on page load.

It’s important to remember that, when namespacing URL parameters in Lightning, any reference made to them in a condition, action, etc, on a Skuid page is also namespaced.

Note

If moving pages from Salesforce Classic to Lightning, you’ll need to update the page parameters and any conditions, actions, etc with the namespace prefix in order to maintain functionality.