Custom fields
Structured, typed data attached to a job or a workstation, such as a part number, a load case, or a drag coefficient. Unlike tags, custom fields can be required, which is what makes them usable for governance rather than organization alone.
Your workspace needs Advanced Modeling & Simulation or above. Within a workspace that has it, anyone can create fields on a job, and workspace-level fields need Workspace Admin rights.
Choose a scope first
Scope decides which jobs a field appears on and who is allowed to change it. Pick it before anything else, because moving a field between scopes later means recreating it.
Rule of thumb: workspace for context that must always exist on every run, job for everything else.
A job's fields travel with it. Save a job as a template and the template keeps the fields you defined, so every job launched from it starts with those fields already in place. That is how a team shares a set of fields without needing an admin, but the fields are still job-scoped: each new job gets its own copy, which that job's owner can edit.
Context, Input and Findings
Every field belongs to one of three categories, which appear in the Details pane alongside Rescale's built-in fields. The split follows the shape of a simulation: why you ran it, what you fed in, and what you concluded.
Empty categories are hidden from end users, so an admin can define only what's needed. Within a category, the order you set is exactly the order people see.
Fill in values
Fields appear on the job page both during setup and after launch, and whether a field is required changes when you are allowed to fill it.
Because optional fields can be filled after a run completes, they're the natural place for findings. A converged value, a pass/fail conclusion. Required fields lock at launch, so they're for inputs and context only.
Add fields to a job
- On a new job, click Add Custom Fields.
- Under the relevant category, click Add Field; set a name and field type.
- Save. Fields you added at job scope can be edited, reordered, or removed.
- To reuse them, click Save as Template. Every job launched from that template starts with the same fields and any values you pre-filled.
Fields inherited from the workspace are read-only. They can't be reordered or deleted from an individual job, which is what makes governance stick. Fields that came in from a template are yours to edit, because they arrive as that job's own fields.
Add workspace fields (admin)
Requires Workspace Admin access.
- Go to Policies → Custom Fields.
- Pick the Batch job fields or Workstation fields tab. The two are configured independently, so a field you define for jobs does not appear on workstations and the reverse.
- Choose Start with Defaults (recommended) or Start Empty. The defaults give you a working set to edit rather than a blank page: Study, Study Requestor, Study Expected Completion Date, Development Status and Objective under Context; Part Number, Profile Variation and Diameter under Input; and Simulation Outcome, Coefficient of Drag, Report and Convergence Plot under Findings.
- In the relevant section, click Add Field. Set:
- Name and field type
- Required or Optional
- Single Valued or Multiple Valued (1:1 or 1:many)
- Optionally Show Instruction Fields for a description and placeholder
- Duplicate, remove, or reorder as needed, field order is exactly what users see.
- Save Changes.
A new required field applies to every future submission, including automated ones. Scripts that don't supply it start failing with field xyz is required.
Tell API users before you roll one out, and give them time to update. This is the most disruptive thing on this page.
Field types
The type you pick decides what can be entered and, more importantly, what can be entered wrongly. There is no custom validation anywhere in the system, so an Option List is the only way to constrain what someone types. Reach for Text only when the value is genuinely free-form.
There's no custom validation. A Text field accepts anything. If a value must conform, use an Option List instead of Text.
What happens when a field changes
A workspace-level field is not a rule applied at submission time and then frozen; it is part of the workspace's current definition. So adding a field makes it appear on existing jobs too, not only on jobs created afterwards, and it shows up with no value until someone fills it in.
Removal works the same way. Taking a field out of the workspace settings takes it off the existing jobs that carried it, not just off future ones.
So both directions cut deeper than they look. Adding a field opens an empty slot on every job already in the workspace, which is useful if you mean to backfill and noise if you don't. Removing one takes a column off work that is already finished, so if anyone was relying on that data, export it first.
Required fields are the exception that matters: a required field locks at launch, so adding one cannot retrospectively block a job that has already been submitted. What it does affect is everything not yet submitted, including automated submissions.
Export
Custom fields come out in both the Jobs page CSV export and the Billing CSV, each field as its own column after the built-in ones. Appearing in the Billing CSV is the part that matters and the part tags don't do, because it is what makes cost-per-part-number or cost-per-study analysis possible. See billing & reports.
API
Fields and values can be created and populated through the REST API.
Errors on submission:
A post-processing script can write findings back into fields, extract a converged value from solver output and populate the Findings category automatically. See automations.
Two Rescale-provided automations do this for you. Metadata Extraction reads input variable names and values out of your solver files and writes them into custom fields, and AI Extraction converts solver output into a format AI Physics can train on. Together they are the prerequisite for building a surrogate model, because the custom fields Metadata Extraction populates become the input variables the model learns from. See launching a training session.
Pre-fill with templates
Enter values once, then Save as Template or update an existing one. Later jobs arrive pre-populated instead of needing manual entry each time. See reuse a job setup.
Related
- Tags — free-form labels, when structure isn't needed
- Automations — populating fields from job output
- Reuse a job setup — templates that carry fields and values
- Create and submit a job — filling fields at setup
- Billing & reports — fields as CSV columns