A case library uses shared step blocks that many cases reference. What typically happens to that sharing when the library is exported into a different case-management product?
answer
- a reference only resolves inside its product
- exporters inline rather than dangle
- content survives, the link does not
- identical step sequences repeated everywhere
- one edit becomes many edits
basics
~20 sSharing is normally flattened. Each referencing case receives its own inlined copy of the block's steps, so the library reads correctly on day one while the single edit that used to update every case is gone.
solid answer
~50 sA shared block is a reference, and a reference only means something inside the product that resolves it. Exporters therefore take the safe route and **inline** it: every case that pointed at the block gets its own copy of the step text written into its own step list. Nothing is lost in reading terms — each case is complete and correct — and the maintenance property that justified the block is silently gone, because fixing the shared procedure now means editing every copy. It is easy to miss precisely because the import looks perfect. The tell is repetition: the same step sequence written out verbatim across many cases. Decide deliberately what to do about it — re-create the blocks in the target before loading and map the inlined copies back to references, accept the flatten and plan a de-duplication pass, or accept it permanently if the target has no such concept, and cost the maintenance.
go deeper
Know that a shared block of steps is a reference, and that exporting a library to a different product usually writes those steps out in full into each case that used them.
Explain the trade the exporter is making — a complete self-contained case rather than a pointer the target cannot resolve — and what that costs: content survives, the single point of edit does not.
Show how you would detect it before it hurts, during a rehearsal load rather than after cutover, and lay out the three real responses along with which one you would pick and why.
Own the consequence for the library's shape: if the target cannot express sharing, decide whether the library is restructured or the extra maintenance is accepted, and put that cost in the migration case rather than leaving it to emerge.
## Why sharing flattens A shared step block is a small piece of indirection: one definition of a common procedure, referenced from many cases, edited once. That indirection lives entirely inside the product that resolves it. The moment the library is serialised for another product, the exporter faces a choice with an obvious safe answer. - **Emit the reference.** Correct only if the target has the same concept *and* the block itself has already been created there with a matching identity. Two conditions, neither of which an exporter can assume. - **Inline the steps.** Always produces a readable, self-contained case. Nothing dangles, nothing points at something the target has never heard of. Exporters overwhelmingly choose the second, and it is the defensible choice: a complete case beats a broken pointer. The consequence is simply not announced, and the import reports success because nothing failed. ## What you actually lose Not content — every case still contains every step, in order, reading exactly as it did. What goes is the **maintenance property**: - **One edit becomes many.** When the shared procedure changes, the change has to be repeated in every case that once referenced the block. - **Consistency stops being structural.** Previously the cases could not disagree about the procedure; now they can, and they will, as copies are edited unevenly. - **Intent disappears.** The library no longer records that these steps were *the same thing* rather than coincidentally similar text, so a later reader cannot recover the grouping. - **The library grows.** More text, more to review, and diffs that are noisier for the same amount of real change. ## How to spot it after the fact - **Look for verbatim repetition.** The same opening sequence written out in full across many cases is the signature, especially set-up procedures such as signing in or preparing a fixture. - **Compare block usage against the target.** If the source shows one block referenced by a large group of cases and the target shows that many identical step sequences, the reference is gone. - **Check whether the target lists any blocks at all.** An empty shared-block area after a load of a library that leaned on them is conclusive. - **Try an edit.** Change the procedure in one case and see whether anything else moves. If nothing does, you have copies. ## Your options, chosen deliberately 1. **Re-create the blocks in the target first, then map on import.** Create the shared procedures in the new product before the load, and have the import replace each inlined copy with a reference to the matching block. The most faithful outcome and the most work — it needs a reliable way to recognise which inlined sequences correspond to which block, which is why doing it before the bulk load, while the source can still be consulted, matters. 2. **Accept the flatten, then de-duplicate later.** Load the flattened library, get the team working, and run a pass afterwards to extract the repeated sequences back into blocks. Realistic, but the pass gets deprioritised, and every day it waits the copies drift further apart and become harder to reunite. 3. **Accept it permanently.** Correct when the target simply has no shared-block concept. Then flattening is not a defect, it is the target's model — but the maintenance cost is now real and belongs in the estimate rather than in a surprise six months later. What is not an option is not noticing. The whole failure mode of this one is that it produces a library which looks completely healthy. ## What it changes about the plan Check for shared blocks during the rehearsal load, not the real one. Whether the target has the concept, whether its importer can create references, and how many cases depend on the sharing are all questions with answers before the cutover date is set — and all of them become expensive after it.
- If you wanted to preserve the sharing, when in the cutover would you do the work?Before the bulk load, during the rehearsal. Create the shared procedures in the target first, then import cases mapped to reference them, while the source is still available to confirm which cases used which block. After cutover the copies begin to drift and the mapping you would need to reconstruct becomes guesswork rather than a lookup.
- The new product has no shared-step concept at all. What changes?The flatten becomes the target's model rather than a migration defect, so stop treating it as recoverable. Put the added maintenance into the estimate, agree how a common procedure change will be rolled out across copies, and consider whether the library should be restructured so fewer cases repeat the same set-up.
saying these in an interview costs you the question
- Assumes references survive because the import showed no errors
- Thinks flattening loses step content rather than the link
- Plans the de-duplication pass and never schedules it
- Ignores that the target may lack shared blocks entirely
- Discovers the flatten only when a procedure changes