These are advanced, permission-restricted features. Resources and Sitemap settings only appear for users with full page update access. If you can’t see them in a page’s Settings, ask an administrator to check your permissions (see Users and permissions).
Resources
A Resource is a piece of data that the page fetches when it loads, so you can use that data in your content. Resources are configured in a page’s Settings → Resources — they are not blocks you drag onto the page. Think of a Resource as a data layer sitting behind the page: it fetches the data first, then your blocks and settings can reference it. To add one, open the page, go to Settings, find the Resources section, and click Add resource. There are three types of Resource:| Resource | What it does |
|---|---|
| Job | Fetches the data for a single job by its ID, so you can display job details anywhere on the page. This is what turns a page into a job detail page. |
| Redirect | Sends the visitor straight to another URL. Use a Permanent (301) redirect when a page has moved for good, or a Temporary (302) redirect for a short-lived diversion. |
| Hardcoded list | A fixed list of values you define by hand, for building repeating content without an external data source. |
The Job resource
The Job resource has two settings:- Job ID — which job to fetch. You can enter a literal inploi job ID (the number shown in Hiring → Jobs), or a dynamic value such as
{{params.id}}so the ID comes from the URL (see Dynamic slugs below). - Conditions (optional) — rules that check the fetched job before showing the page. Each condition compares a job field against a value; if it matches, the chosen Action runs. Today the only action is Page not found, which returns a 404. For example, compare Compare field
custom_data.is_internalEqualstrueto hide internal-only roles from the public site.
job by default. That key is how you refer to the fetched data in your content — for example {{resources.job.title}}.
Dynamic slugs and parameters
A normal page has a fixed slug, such as/about. A dynamic slug contains one or more wildcard segments written with a colon, such as /job/:id. A single page with that slug serves every matching URL — /job/79000019, /job/79000020, and so on — and the value from the URL becomes available to the page as a parameter.
- Write dynamic segments with a colon prefix:
/job/:id,/team/:department,/:region/:city. - You can use up to three dynamic segments in one slug.
- The value from the URL is available as
{{params.<name>}}. For/job/:id, the visited URL/job/79000019gives you{{params.id}}=79000019.
/job/:id with a Job resource whose Job ID is set to {{params.id}}. The job ID is read from the URL and used to fetch that specific job.
Interpolation
Interpolation lets you drop live values into your content using double curly braces:{{path.to.value}}. When the page renders, each token is replaced with the real value. Interpolation works in Rich text blocks, in SEO fields (page title, meta description), and in the Job resource’s Job ID field.
You can provide a fallback after a pipe, used when the value is empty: {{resources.job.pay|Competitive salary}}.
Common values you can reference:
| Token | What it resolves to |
|---|---|
{{params.id}} | A value from the URL of a dynamic page (here, the :id segment) |
{{resources.job.title}} | The job title from a Job resource keyed job |
{{resources.job.description}} | The full job description |
{{resources.job.city}} | The job’s city (also town, country, postcode) |
{{resources.job.pay}} | The pay text |
{{resources.job.company_name}} | The employer name |
{{resources.job.category}} | The job category (also industry, employment_type, contract_type) |
{{resources.job.custom_data.<key>}} | Any custom field passed in from your ATS |
Conditions
Conditions show or hide a section, column, block, or field depending on live data. They use the same values as interpolation. For example, you can show a “Remote-friendly” banner only whenresources.job.location_type Equals REMOTE, or hide a salary block when resources.job.pay is empty.
Conditions are set on the element itself in the editor. They’re useful on job detail pages to adapt the layout to each job without building separate pages.
Conditions on an element (a block or section) are different from the Job resource’s own Conditions. Element conditions decide whether a piece of content is shown; the Job resource’s conditions decide whether the whole page loads at all (returning a 404 when matched).
Job Search block vs Job resource
These sound similar but do different jobs:- The Job Search block shows a searchable, filterable list of jobs — ideal for a
/jobslisting page or a location page. It’s covered in Creating a landing page. - A Job resource fetches one job’s data so you can build a detail page for that role.