> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inploi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Resources and dynamic pages

> How to build data-driven pages in the CMS using Resources, dynamic slugs, interpolation, and conditions.

Most CMS pages are static: the content you type is the content candidates see. Some pages need to be data-driven instead — a single page template that shows a different job depending on the URL, or a block that only appears when a job meets certain criteria. This page explains the building blocks that make that possible: **Resources**, **dynamic slugs**, **interpolation**, and **conditions**.

The most common use of these features is a [job detail page](/studio/cms/faqs/create-a-job-detail-page) — one page template that renders any job by its ID.

<Note>
  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](/studio/settings/users-and-permissions)).
</Note>

## 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](#dynamic-slugs-and-parameters) 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_internal` **Equals** `true` to hide internal-only roles from the public site.

When you add a Job resource, it is given a **Resource key** of `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/79000019` gives you `{{params.id}}` = `79000019`.

The typical pattern for a job detail page is a slug of `/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                               |

<Tip>
  In a dynamic string field, type `{{` and Studio suggests the values available for that page based on the Resources you've configured. This is the quickest way to see exactly which job fields you can use.
</Tip>

## 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 when `resources.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.

<Note>
  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).
</Note>

## 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 `/jobs` listing page or a location page. It's covered in [Creating a landing page](/studio/cms/faqs/create-a-landing-page).
* A **Job resource** fetches **one** job's data so you can build a **detail** page for that role.

Entering a job ID into a Job Search block will not create a detail page — you need a Job resource for that.

## Related articles

* [Creating a job detail page](/studio/cms/faqs/create-a-job-detail-page)
* [Creating location-specific pages](/studio/cms/faqs/location-specific-pages)
* [Why isn't my job page showing?](/troubleshooting/job-page-not-rendering)
* [The page editor](/studio/cms/pages/page-editor)
* [Glossary](/studio/cms/glossary)