An issue tracker refuses to create an item unless a particular field is set, and the case repository filing the defect holds no value for it. How do you resolve that?
answer
- the create is rejected, not degraded
- name a source before a value
- constant, derived, prompted, or renegotiated
- a plausible placeholder is the trap
basics
~20 sName a source rather than inventing a value: a constant the team stands behind, something derived from the run or the case, a person prompted at filing time, or a destination change that drops the demand.
solid answer
~50 sThe mandatory field is a hard gate — without a value the create is rejected, so this must be resolved before the integration works at all. There are four honest resolutions and one dishonest one. Honest: supply a **constant** the team is willing to defend for every item filed this way; **derive** it from something the repository genuinely knows, such as the cycle, the environment or the case's own attributes; **prompt** the person filing and let them choose; or go back to the destination and stop the field being mandatory for this item type, possibly by filing as a different type. The dishonest resolution is a placeholder — an empty-ish string, a dash, a catch-all list member — chosen because it makes the create succeed. That writes a fact nobody checked into a field other people filter and report on, and it is indistinguishable afterwards from a value someone meant.
go deeper
Know that a mandatory field blocks creation entirely, so a defect simply never gets filed. Be able to say the value must come from somewhere named rather than being made up on the spot.
Walk through the options and their mechanics: a constant, a value derived from the run or the case, a prompt at filing time, or changing the destination so the field is not demanded.
Show the downstream damage a plausible placeholder does to filters, saved views and the counts read from them, and explain how you would make a stand-in loud and time-boxed instead.
Frame it as an agreement between two teams. Decide who owns the mandatory-field list, what an integration is allowed to assert, and how that is reviewed when either side reorganises.
## Why this is a gate, not a wrinkle A tracker that marks a field mandatory on an item type will refuse the create outright when it is missing. There is no partial success to inspect later: the defect is simply never filed, and the failure surfaces as an integration error at exactly the moment someone was trying to record a failing run. That makes a mandatory field with no source the single most common reason a freshly configured repository-to-tracker link does not work. The underlying mismatch is real rather than accidental. The two systems were configured by different people for different purposes. A tracker's mandatory fields encode what the receiving organisation needs in order to *plan and route work*: which component, which team, which release train, which cost centre. A case repository knows about *verification*: which case, which cycle, which environment, what the executor observed. Some of what the tracker demands the repository has never had a reason to record. ## The four honest resolutions 1. **A constant.** One value used for every item this integration files. Legitimate when the value is genuinely true of every such item — the component that owns this suite, the team that triages it. The test is whether someone will defend it aloud, not whether it satisfies the tracker. 2. **A derived value.** Compute it from something the repository genuinely holds: the cycle, the environment, the case's own attributes, the suite the case sits in. Stronger than a constant because it carries information, and it can be checked against reality later. 3. **A prompt at filing time.** Ask the person raising the item. Correct whenever the value is a judgement rather than a fact — how urgent the work is, who should look at it. Its cost is that unattended filing from an automated run cannot use it, so a prompt-only mapping quietly restricts who may file. 4. **Change the destination.** The most under-used option. If a field is mandatory only because the item type was tuned for planned work, the right fix may be to file as a different item type, into a different project, or to persuade the tracker's owners that the field should not be demanded at creation. Trackers frequently mark fields mandatory for *humans on a form*, and an integration inherits that demand without having inherited the human. ## The dishonest resolution, and why it costs more than it saves A placeholder — a dash, the word unknown, a catch-all list member, the first option in the list — makes the create succeed today and produces a defect that arrives already carrying a false fact. The costs land later: - **Filters and saved views** treat the placeholder as data. Items filed by the integration cluster into whichever bucket the placeholder points at. - **Counts read off those views** inherit the distortion, and no one reading them can tell the placeholder apart from a deliberate choice. - **Nobody circles back.** The placeholder is silent, so there is no moment at which it announces itself as a stand-in. - **The gap it hides never gets fixed.** The tracker's owner never learns that the field is unanswerable from the filing side. If you must ship something to unblock, make the stand-in **loud** rather than plausible: a value that is obviously an integration artefact and can be searched for, plus a note in the mapping saying who owes the real source and when. A visible stand-in is a debt with a name on it; a plausible one is a lie with no expiry. | Resolution | Fits when | Main cost | |---|---|---| | Constant | The value is true of every item filed this way | Rots silently when the team or component changes | | Derived | The repository already holds something equivalent | Needs a rule that stays correct as the source drifts | | Prompt | The value is a judgement, not a fact | Rules out unattended, automated filing | | Change the destination | The field was made mandatory for human forms | Requires agreement from the tracker's owners | | Placeholder | Never, as a permanent answer | Writes an unchecked fact into other people's reports | ## Getting the conversation right This is nearly always a negotiation, not a configuration exercise. The people who made the field mandatory are usually not the people wiring up the integration, and they were solving a real problem — items arriving without enough context to route. The productive framing is to show them exactly what the filing side does and does not know, and ask which of the four resolutions they prefer for their own field. A mandatory field the filing system cannot answer is a defect in the agreement between two teams, and it is fixed on that level, not by finding a value that gets past the check.
- You choose a constant for a mandatory field. What makes it go bad later, and how would you notice?Constants rot when the world behind them changes — the component is renamed, the owning team splits, the suite moves to another product. Nothing announces it, because the create keeps succeeding. Notice it by reviewing the constant whenever the destination changes, and by occasionally sampling recently filed items to ask whether the value is still true rather than merely accepted.
- When is prompting a person the wrong answer even though the value really is a judgement?When the filing is unattended. A failing run that files automatically has nobody to prompt, so a prompt-only mapping either blocks automated filing entirely or silently falls back to something else. If unattended filing matters, derive a defensible starting value and let triage correct it, rather than making a human the only possible source.
saying these in an interview costs you the question
- Fills the field with a placeholder to make the create pass
- Treats a mandatory field as advisory rather than a hard gate
- Never questions whether the field should be mandatory here
- Picks the first list member because it is first
- Assumes the tracker will supply its own default