Build Dynamic Teams rules on a field specific to your organization by adding it as a custom attribute. Dynamic Teams works out of the box with a set of default attributes from your identity provider. When the field you need to build a rule on is not in that default list, you can have it added as a custom attribute. This guide covers the difference between default and custom attributes, the setup workflow, and how to use a custom attribute once it is ready.
ℹ️ Who this is for: Account Admins who need a Dynamic Teams rule on a field that is not in the default attribute dropdown. To build the rules themselves, see Setting up Dynamic Teams.
⚠️ Requires a SCIM connection. Like all of Dynamic Teams, custom attributes are available to SCIM-connected customers only. SAML-only customers without a SCIM connection will not see this functionality.
1. Default vs custom attributes
Spekit supports two kinds of attributes in Dynamic Teams rules.
| Attribute type | What it is | Setup needed |
|---|---|---|
| Default attributes | Predefined attribute keys delivered by your identity provider. | None. They appear in the rule dropdown automatically. |
| Custom attributes | An attribute key specific to your organization that is not in the default set. | Spekit configures it in WorkOS, and you map your IdP field to it. |
Most teams build their rules entirely from default attributes. Reach for a custom attribute only when the field you need is not already in the dropdown.
2. The custom attribute workflow
Adding a custom attribute is a coordinated workflow between your team and Spekit support.
- Submit a support request to Spekit to add a new custom attribute.
- Spekit adds the custom attribute option in WorkOS.
- Launch the "Edit attribute mapping" flow from User Management in Spekit, and define the mapping for that attribute, so Spekit knows which field from your identity provider feeds it.
- Save the mapping in the WorkOS attribute mapping interface.
- Return to Spekit and run "Sync now" to pull the attribute information into Spekit for your users.
- Use the attribute to define team rules on the team edit screen.
Example: Your directory has a "Region" field that is not in the default attributes. You request it, Spekit adds it in WorkOS, you map your Region field to it, run Sync now, and then build a rule like Region contains EMEA to auto-populate a regional team.
💡 Pro tip: Before you open the support request, know exactly which identity provider field you want and what it is called on your side. Naming the source field up front makes the mapping step quick and avoids back-and-forth.
3. Using the attribute in a rule
Once the custom attribute is defined, mapped, and synced, it appears in the attribute dropdown on the create or edit team screen, right alongside the default attributes. From there you build rules with it exactly like any other attribute, using Equals or Contains and combining rules with ALL or ANY. See Setting up Dynamic Teams.
ℹ️ Run Sync now first. A custom attribute will not carry user values until you run Sync now after saving the mapping. If a new rule on a custom attribute is not matching anyone, an un-synced mapping is the first thing to check.
4. Best practices
| Best practice | Why it matters |
|---|---|
| Exhaust default attributes first | Most rules can be built without a custom attribute. Check the dropdown before requesting one. |
| Name the source field before requesting | Knowing your exact IdP field name up front makes the support request and mapping fast. |
| Always Sync now after mapping | Rules on a custom attribute only work once user values are pulled in. Running Sync now is what makes the attribute usable. |
| Reuse one custom attribute across teams | A single custom attribute like Region can power rules on many teams, so request the general field, not a one-off. |