This is a genuine contradiction because a free-text field allows completely unconstrained input, meaning different users will phrase conceptually identical reasons in many different ways, such as "price too high," "pricing concerns," and "client said too expensive," which a reporting tool cannot reliably group together into meaningful, accurate aggregate categories. Reliable reporting on "top reasons" fundamentally requires consistent, controlled values, which only a Picklist field type can provide. The resolution is to write the requirement specifying a Picklist field with a defined, agreed set of standard loss-reason values, rather than free text, ensuring the stated reporting goal is actually achievable, and if stakeholders are concerned about losing nuance, an optional supplementary free-text "additional details" field can be added alongside the Picklist to capture extra context without sacrificing the reportable, structured primary reason field.

This requirement implies the relationship between the parent and child objects must be Master-Detail rather than Lookup, because Roll-Up Summary fields, which provide exactly this kind of automatic sum, count, minimum, or maximum calculation displayed on a parent record based on its related children, are only available when the underlying relationship is Master-Detail. A Lookup relationship does not natively support Roll-Up Summary fields, meaning if this relationship were instead built as a Lookup, achieving the stated requirement would require a significantly more complex workaround, such as custom automation or code, rather than simply using standard, native Roll-Up Summary functionality. Recognizing this implication while writing the requirement allows the BA to either specify the Master-Detail relationship explicitly upfront, or to flag this as a specific point requiring technical confirmation during a Fit-Gap workshop.

Cascade-delete behavior, where deleting a parent record automatically deletes all its related child records, is a genuine business-relevant consequence with real implications for data retention and potential loss of historical records, not merely an internal technical mechanism with no real-world impact stakeholders should care about. If a stakeholder later deletes a parent record without realizing this consequence, and discovers important related child records, such as an audit trail or approval history, were unexpectedly and irreversibly deleted along with it, this creates a genuinely damaging surprise that erodes trust in the BA and the overall solution, especially since this exact outcome could have been explicitly surfaced and consciously agreed to in advance. Flagging this explicitly during requirements gathering, and gaining genuine stakeholder confirmation that this behavior is acceptable for the specific business process in question, prevents this entirely avoidable category of surprise and ensures an informed decision was genuinely made rather than a technical detail being silently decided without the business's awareness.

A BA needs sufficient data model fluency to write technically credible, genuinely buildable requirements and to participate confidently in technical discussions, understanding concepts like object types, field type implications for reporting and automation, and the practical consequences of relationship type choices, without needing the deep, comprehensive mastery an Administrator requires to actually configure every detail of the platform, including advanced security models, complex automation logic, and the full technical intricacies of deployment and governor limits. Maintaining this distinction matters because attempting to develop full Administrator-level expertise would represent significant time investment that ultimately distracts from the BA's core, distinctly different value, which centers on requirements, stakeholder management, and translating business need into clear specifications, while having genuinely insufficient data model knowledge would mean writing requirements that are technically naive, vague, or unknowingly infeasible, undermining the BA's core credibility and effectiveness with the technical team they work alongside.

The appropriate approach is to openly acknowledge the genuine uncertainty rather than confidently guessing and potentially recommending an unnecessary Custom Object when a suitable Standard Object might already exist, or conversely forcing a genuinely unique business concept into an ill-fitting Standard Object structure. Salesforce includes numerous Standard Objects beyond the most commonly discussed ones, and a BA cannot reasonably be expected to have memorized every single one along with its exact intended use case, especially across different Salesforce products and editions that may have different sets of available Standard Objects. The professional response is explicitly raising this specific uncertainty with a technical expert, such as an Admin or Architect, during Gap Analysis or Fit-Gap discussions, treating it as a genuine question requiring technical confirmation rather than presenting an unverified guess as if it were a confident, settled recommendation.

Being able to read a schema diagram allows a BA to participate as a genuine, informed peer in technical Design discussions where an Architect or Admin shares such a diagram, immediately understanding which objects relate to which others, the nature of those relationships, such as Lookup versus Master-Detail, and the practical implications that follow, like whether a child record can exist independently or whether deleting a parent will cascade-delete its children. Without this reading fluency, a BA would need to passively wait for someone else to translate the diagram's technical notation into plain language for every point of discussion, slowing down the conversation and limiting the BA's ability to immediately spot a potential business-relevant consequence, such as an unexpected cascade-delete implication, and raise it proactively in the moment rather than discovering it later. This reading fluency directly supports the BA's core responsibility of catching and surfacing genuine business implications hidden within technical design decisions, exactly the kind of value demonstrated throughout this module's relationship-type exercises.