I85PREP
⌘ K
ACP-120 study materials
ACP-120 study resources

Cost Center: Contexts, Field Configurations and Screens

ACP-120 · Put your knowledge to work in context.

All case studies

Cost Center: Contexts, Field Configurations and Screens

Northwind runs 6 company-managed projects on shared schemes. Cost Center is a select list with a single global context and three options: CC-100, CC-200, CC-300. The FIN team now needs two additional options, CC-900 and CC-910, and must make the field mandatory on every issue type it uses. The other five projects must keep exactly the three original options and must not be forced to populate the field. Finance also insists that existing FIN issues retain their current values after any change. Separately, OPS reports that Cost Center does not appear on Bug issues at all, even though the OPS project lead confirmed the field is not hidden in the field configuration. OPS uses three issue types - Bug, Task and Spike - which the lead believes are all mapped to the default screen scheme.

1. How do you give FIN the two extra options without exposing them to the other five projects, and what ordering mistake would destroy existing data?

Read the worked answer

Add a second context. Contexts, not permissions, are the only scope for select-list options.

  1. Cost Center → Contexts and default value → Add context, name it FIN.
  2. Before associating any project, add all five options to the new context: CC-100, CC-200, CC-300, CC-900, CC-910. Keep the option values identical to the originals - values, not display names, are what carry across a context move.
  3. Associate the context with FIN only. The remaining five projects stay on the default context and see three options.
  4. Add a context description explaining why the split exists; six months from now nobody will remember.

Why not simply add the options to the existing context: a single global context is evaluated by every project using the field, so CC-900 and CC-910 would become selectable everywhere.

The ordering mistake that destroys data: associating FIN to the new context before populating it with CC-100/CC-200/CC-300. On association, FIN issues are re-evaluated against the new context; any value with no matching option is dropped, silently and without an undo. Populate first, associate second, then spot-check five FIN issues. Also check whether any automation compares on the option value - renaming options in the new context while keeping values is safe, changing values is not.

2. How do you make the field mandatory for FIN only? Name the exact object that controls this, and the two traps that make a 'required' field behave unexpectedly.

Read the worked answer

Required is a field configuration property - not a context, not a screen.

  • Check Fields → Field configuration schemes and find which field configuration FIN's issue types map to. If FIN shares a field configuration with the other five projects, create a new one (or copy the existing), set Cost Center to Required, and attach a field configuration scheme that maps FIN's issue types to the new configuration. Field configuration schemes are per project and issue type, so FIN can diverge without touching anyone else.

Trap 1 - the field must be on the screen. A field marked required in the field configuration but absent from the Create screen does not quietly become optional; users get an error and cannot create the issue. Confirm Cost Center is on FIN's Create and Edit screens for every issue type in FIN.

Trap 2 - the field must exist in the field configuration. A field on the screen but missing from the field configuration renders with default behaviour, so any 'required' setting you thought you applied is not in force. Verify both lists, not just one.

Finally, test as a non-admin user in FIN. Admins routinely see the field already populated on issues they created themselves and conclude the requirement works when it does not.

3. Why is the field missing on OPS Bugs despite the field configuration check? Walk through the diagnosis.

Read the worked answer

Field configurations do not control visibility. The project lead checked the wrong object.

Visibility is governed entirely by screens; field configurations govern required/optional, description and renderer. A field can be perfectly configured and still never render because no screen shows it.

Diagnosis order:

  1. Project settings → Issue types → Bug and follow the screen scheme attached to Bug. Screen schemes map per operation (Create, View, Edit) and per issue type - the lead's assumption that all three OPS issue types share the default screen scheme is exactly what needs verifying, not assuming.
  2. Open the screen used for Bug's View and Create operations and check whether Cost Center is listed. If it is absent, no field configuration change can make it appear.
  3. If Bug genuinely shares a screen with Task and Spike, and Task shows the field, then the cause is elsewhere: the field may have been added only to the Edit screen, or Bug may be mapped to a different screen scheme after all.
  4. Add the field to the correct screen, then re-check the field configuration for required/optional and description.

Two settings, two places. Record both in the project documentation so the next person does not repeat the same half-diagnosis.