Single space supporting multiple affiliates - Best Practices Question

[Paul Liebrand]

We operate a single service space/project to manage IT requests for six different affiliates we support. Most request categories are consistent across affiliates, but a few affiliates have unique questions/requirements for onboarding/offboarding workflows.

I'm looking for guidance on best practices for structuring request types and forms in this scenario.

Which approach is recommended:

Single request type + conditional form fields
Use one onboarding (and offboarding) request type, with conditional sections/fields that appear based on the selected affiliate.

OR

Separate request types for affiliates with unique needs
Create a standard onboarding request type for common requirements, and additional affiliate-specific request types only where requirements differ.

If option #2 is recommended, should we use Organizations to segment affiliates and limit/assign request types by organization (or otherwise tailor what each affiliate sees)?

Any recommended patterns (including maintainability and reporting considerations) would be greatly appreciated.

[Arkadiusz Wroblewski · Accepted solution]

Hello @Paul Liebrand 

There is not one single Atlassian best practice for this design, so this is more my recommendation based on maintainability than a hard product rule.

My usual approach would be:

1. keep one standard onboarding/offboarding request type for the common process
2. use conditional fields / form sections for smaller affiliate differences
3. only create affiliate-specific request types where the requirements are different enough that one shared form becomes difficult to maintain

For Organizations, I would mainly use them if you need to control which affiliates can see which request types, since Jira Service Management supports restricting request types to selected users, groups, customer accounts, or organizations.

So from my perspective, the sweet spot is usually: shared request type for the common path, separate request types only for real process differences, and Organizations/restrictions/Security schemes where visibility needs to differ.

Again, that part is my design judgment, not an official Atlassian rule. Atlassian provides the building blocks such as request types, forms, restrictions, and portal groups, but the final structure depends a lot on how different your affiliate processes really are.

We can provide some advices, choice is yours depending on business needs. 🤠🤗

[Olha Yevdokymova_SaaSJet]

Hi @Paul Liebrand 

Both approaches are valid — the right choice depends on how much the affiliate-specific requirements diverge and how you want to maintain things over time.

On the native JSM side, Organizations can help segment what affiliates see in the portal, but the conditional logic and form customization available natively is fairly limited when requirements start branching significantly per affiliate.

Here's how I'd think about the two options:

Option 1 — Single request type + conditional form fields works well when:

• The core data you're collecting is the same across affiliates, with only a handful of unique fields per affiliate
• You want one request type in reporting and a clean ticket structure
• You're okay with a longer form that hides/shows sections dynamically

The downside is that as affiliates multiply or their requirements diverge, maintaining one large conditional form gets unwieldy quickly.

Option 2 — Separate request types for affiliates with unique needs works better when:

• The workflow or SLA treatment differs per affiliate (not just the fields)
• You want cleaner queue segmentation and filtering in Jira
• You plan to use Organizations to scope what each affiliate sees in the portal

This approach scales more cleanly from a maintenance and reporting standpoint, especially if you're tracking metrics per affiliate.

One approach worth exploring — if you're open to add-ons, our team at SaaSJet built Smart Forms for Jira specifically for scenarios like this.

For your case, a hybrid pattern tends to work well:

• One base form handles the common onboarding/offboarding fields
• An "Affiliate" dropdown at the top drives conditional logic — affiliate-specific sections appear only for the relevant affiliate, so the form stays clean for each submitter
• The form maps to a single request type, but field values (including the affiliate selection) feed into Jira fields you can use for filtering, SLA rules, and reporting
• If you need true per-affiliate variants, forms can be cloned across projects and adapted independently — so you maintain a common baseline but customize per affiliate without rebuilding from scratch

For Organizations-based segmentation, you can embed or share the right form variant per affiliate via link or Confluence page — no portal login required for external users, and each affiliate only sees what's relevant to them.

This keeps your request type count manageable while still giving you the flexibility to handle affiliate-specific edge cases.