One reusable pipeline runs a Notebook activity that processes digitised-object metadata for whichever branch is specified, but the underlying PySpark code inside the notebook needs to know which branch it's working on for that run. The pipeline already has a branch-code value available as a pipeline parameter. How should that value reach the notebook's code?

A Notebook activity supports base parameters, which inject values from the pipeline, including pipeline parameters, directly into the notebook's runtime as variables the code can reference, which is exactly the mechanism for passing a branch code from the pipeline down into PySpark logic that needs to know which branch it's processing. This keeps a single notebook fully reusable across every branch, driven entirely by what the pipeline hands it each run. Reading the value from a manually updated text file reintroduces a human step into an otherwise automated flow and risks the file being stale or simply forgotten before a run. Hardcoding each branch code and maintaining a separate notebook version per branch recreates the exact duplication problem parameterization exists to solve, multiplying maintenance by the number of branches. Skipping the parameter entirely and processing every branch's data in one undifferentiated pass abandons the requirement that the notebook work on a specific branch per run, and it likely changes the shape and meaning of the output the reformatting or downstream steps expect. The caveat: base parameters must be declared inside the notebook itself as parameter-tagged variables for the pipeline's values to actually bind to them at run time. A concrete check: run the pipeline with two different branch codes and confirm the notebook's output reflects only the intended branch's data each time.