Learn how Request Types shape request behavior and why some settings carry forward to existing Requests
A Request Type defines the behavior and requirements for workforce requests within an Industry. Request Type settings control how requests are created and which information users must provide during the request process. Request Type settings are configured separately for each Industry.
Many Request Type settings become burned-in (copied) settings when a Request is created. These settings are copied from the Request Type to the Request at creation time and do not automatically update when the Request Type changes later. Understanding how burned-in settings behave can help administrators manage configuration changes more effectively.
Jump to what you want
Why it matters
- Request Types control key request behaviors and requirements.
- Request Type settings affect the user experience during request creation.
- Changes to Request Types can affect future Requests differently than existing Requests.
- Understanding burned-in settings helps administrators predict the impact of configuration changes.
Who it's for
- Program Office users responsible for procurement administration.
- Administrators who maintain request configuration settings.
- Users responsible for workforce request governance.
How it helps
- Understand how Request Types influence request creation.
- Identify settings that are burned into (copied to) Requests.
- Anticipate the impact of Request Type changes.
- Reduce confusion when troubleshooting request behavior.
How it works
Request Types contain numerous settings that can be configured for a client. Some of these settings become burned-in (copied) settings when a Request is created. Once copied, those settings become part of the Request and do not automatically change when the Request Type is modified later.
Request Types are managed within a specific Industry and are available through:
Admin > Procurement > Procurement Geography > Country > Industry > Request Types.
Burned-in (copied) settings
A burned-in setting is a Request Type setting that is copied to a Request when the Request is created. Once copied, the setting on the existing Request does not automatically update when the Request Type is modified later.
This design allows Request Type settings to evolve over time while preserving the configuration that was in effect when an existing Request was created. Requests, Offers, and related procurement records continue to use the settings that were originally copied to them.
Example
Consider the following scenario:
- A Request Type is configured so a field is Required.
- A user creates a Request.
- The Request Type is later updated so the field is no longer required.
- Existing Requests retain their original configuration.
- New Requests use the updated Request Type configuration.
This behavior helps maintain consistency for users working with existing Requests and related procurement activities.
Identifying burned-in (copied) settings
As a general rule, settings for Request Type fields that support configuration options Optional, Required, or Does Not Apply are typically burned in, or copied, to the Request when it is created.
Important behavior
| Consideration | Impact |
|---|---|
| Request Types are Industry-specific. | Changes apply only within the Industry where the Request Type is configured. |
| Burned-in settings are copied when a Request is created. | Existing Requests may behave differently from newly created Requests. |
| Changes to a Request Type do not automatically update existing Requests. | Administrators should evaluate the impact of configuration changes before implementing them. |
| Offers and related request records remain consistent when Request Types change. | Users are less likely to encounter unexpected changes after work has already begun. |
| Fields configured as Optional, Required, or Does Not Apply are typically burned-in (copied) to Requests. | Existing Requests can behave differently from newly created Requests after Request Type changes are made. |
Additional considerations
- Review the impact of Request Type changes before modifying production configurations.
- Communicate request-related configuration changes to affected users when appropriate.
- Test significant Request Type changes before applying them broadly.
- Document Industry-specific Request Type configurations for future administrators.
Availability and setup
Request Types are available through Admin > Procurement and are configured separately for each Industry.
Before you begin
Before reviewing or modifying Request Types:
- Identify the Industry that contains the Request Type.
- Determine whether the settings you plan to change are burned-in (copied) settings.
- Consider how the change may affect newly created Requests.
Learn more
Related Procurement articles:
- Workforce procurement configuration reference
- Industries and procurement configuration
- Add a job class
- Add a job title
- Add a rate card class
- Add a rate card
- Associate suppliers with an Industry
- Create a request template
Understanding Request Types and burned-in (copied) settings provides the foundation for managing request behavior across your workforce procurement program.
| Persona Program office users | Modules Administration | Documentation release Beeline Enterprise | Q3 2026 | Feedback? Email us: |