Skip to main content
how-to · Reviewed 2026-11-02 GA

Hardware policies

A hardware policy ties hardware to software. It decides which coretypes a group of members is offered once they have chosen an application, so the pairing you want is the one they find.

Without a policy, a member setting up a job sees every coretype the workspace can reach, whatever they are running. That is a problem when a solver only performs well on particular hardware, or when a coretype is expensive enough that you would rather it was not an option for routine work. A policy answers both by making the rule part of the job setup form: "when Abaqus is selected, always use these three GPU coretypes", or "never offer the high-memory instances for OpenFOAM". Members in the targeted groups then see a coretype list already filtered to what their software is allowed to run on.

Hardware Policies replaced Hardware Filters

Hardware Policies superseded the earlier Hardware Filters feature in November 2025. All existing Hardware Filters were automatically migrated to equivalent Hardware Policies with software set to "ALL," preserving the selected groups and coretypes. No action was required, and the behavior remained identical.

Prerequisites​

  • Workspace admin role for the workspace where you want to create the policy
  • At least one user group configured with members

Create a hardware policy​

  1. Navigate to the workspace admin portal. Switch to the workspace you administer using the workspace name at the top of the left sidebar, then hover your email at the bottom of the sidebar and open the admin entry. What that entry is called depends on the roles you hold, so see navigating between workspaces and admin portals if it is not where you expect.

    The admin portals use the previous interface

    Admin portals remain on the classic top-nav layout rather than the redesigned sidebar. This is expected.

  2. Open Hardware Policies. From the Workspace Admin portal, open the Policies dropdown menu and select Hardware Policies.

    Classic UIHardware Policies is under Policies in the workspace admin portal.

  3. Start creating a policy. On the Hardware Policies page, click Add new Hardware Policy.

    Classic UIThe Hardware Policies page lists all policies and their target groups.

  4. Configure the policy. On the New Hardware Policy screen:

    • Policy name: Enter a descriptive name (for example, CFD GPU Standard or Chemistry High-Memory Only)
    • Groups: Select which user groups this policy applies to
    • Conditions: Add up to 10 conditions. Each condition specifies:
      • Software: One or more software applications (or "ALL" for any software)
      • Action: Whether the policy should always use or never use the selected hardware
      • Hardware: One or more hardware selections to allow or block. These can be individual coretypes, coretype sets and collections, and the selection carries the priority type with it, so On Demand Priority and On Demand Economy of the same coretype are separate choices
    Classic UIEach policy applies to specific groups and can have multiple conditions.

  5. Save the policy. Click Create Policy. It then applies to every member of the groups you selected.

How policies are enforced​

When a user in a targeted group configures a job:

  1. They select their software application on the Software panel.
  2. When they reach the Hardware panel, the coretype list is filtered based on any policies that apply to their group and the software they selected.
  3. Users see only the coretypes that pass all applicable policy rules. If no coretypes match, they see a message explaining that no hardware is available for their selection.

Software set to "ALL" applies to every software selection. Use this to enforce hardware restrictions across a workspace regardless of which application is chosen, or to migrate legacy Hardware Filters, which applied to all software by default.

When more than one policy applies to the same person​

A member in several groups is subject to every policy those groups carry, and the platform resolves them by taking the union of the hardware all the applicable policies allow. Policies add permissions together rather than narrowing each other down.

So if one group's policy says "when Ansys Fluent is selected, always use Emerald or Luna" and another says "when Ansys Fluent is selected, always use Luna or Carbon", a member of both groups sees all three: Emerald, Luna and Carbon.

The same rule decides what happens when policies cover different software. A policy scoped to All Software sets the baseline for anything not named elsewhere, and a software-specific policy adds to it for that one application. A member in a group allowing Luna for all software and another allowing Emerald for Fluent gets Luna when they pick anything else, and both Emerald and Luna when they pick Fluent.

An "All Software" allow defeats a "never use" somewhere else

Because policies combine by union, a never use rule is not a guarantee. A policy scoped to All Software with always use overrides a software-specific never use policy on the same hardware.

Give one group "when Ansys Fluent is selected, never use Emerald", put the same member in a group that says "for All Software, always use Emerald", and the member still sees Emerald for Fluent. The deny does not win.

Treat never use as a default for the groups you control rather than a hard block. If a coretype genuinely must be unavailable to someone, check every group they belong to, because one broad allow anywhere is enough to hand it back.

Why a policy appears to do nothing​

Two causes account for almost every report of a policy not taking effect, and neither is a fault:

The member is not in one of the policy's groups. Policies apply through group membership, so confirm the person is actually in a group the policy targets rather than in a neighboring one.

The hardware list is cached for about five minutes. A newly created or edited policy does not change what a member sees instantly. Wait for the cache to turn over before concluding the policy is wrong, and when you are testing one, give it five minutes before you start changing it again.

Edit or delete a policy​

From the Hardware Policies page, open an existing policy to edit its name, groups, or conditions. An edit takes effect for affected members once the hardware list cache turns over, which is the five minutes described above.

To delete a policy, open it and click Delete Policy. Members of the affected groups then see the full hardware catalog again, subject to any other policies that still apply to them.

Deletion is not reversible, and it is not a pause

There is no way to restore a deleted policy, and nothing warns the affected members that their hardware options have widened. To take a policy out of service temporarily, remove its groups instead: the policy keeps its name and conditions, applies to nobody while the group list is empty, and can be put back by adding the groups again.