Field notes
A software initiative is justified by the effect it has, not by what it contains. And there is always someone who gets that effect. It could be a customer, a case worker or whoever is on call. What effects for whom is therefore the most important question in the whole solution proposal, and this is where it gets answered.
Here you capture the roles that interact with the various parts of the solution. Who does what, how they use it, and above all what effect they get.
A role is a responsibility or a persona, for example Customer, Back-office administrator or Approver. So not a named person, and not a box in the org chart. (People and team shape belong on the Teams tab.)
Every role has a Name and a short Description of what the role does. Map the role to the Bounded Contexts (and data products) it touches. Each mapping gets two free-text fields: an Authorisation that says how the role uses the context, for example "Reads", "Administrates" or "Approves", and an Effect that says what the role gets back.
The purpose is simply to make responsibility and access explicit, and to make clear what effect each role will get.