I like Keith Swenson's post on the subject of Roles because it is a topic that rarely gets this kind of vendor-agnostic deep-dive.?
In the case of a business process, the use of roles is pretty obvious.? If you are modeling the process for managing newspapers articles, you are going to have a role for ?writer? and a bunch of activities that the writer is expected to do, a role for ?editor? and activities that they will do, a role for ?typesetter? and the jobs that they are expected to do, and probably many more roles.? The nice thing about a role is that you can define it once, and use it like a kind of variable.? For article XYZ the writer will be Billy-Bob, the editor will be Dorothy, and so on.? Roles are often represented as a swim lane on a BPMN diagram, and that swim lane contains the activities performed by that role.
Oh but that's only the easy part... Keith goes on to explain why roles are not the titles in your organizational hierarchy (though those organization roles may turn out to be roles in your process). A role is a set of responsibilities that a participant takes on while acting within the process.? Roles can be sticky, or not.?
Keith boils this down to a relationship to a context: "In general, a role is a property of the process instance, not a property of the organizational directory."
Well worth the read for those designing processes for the real world.? It might sound theoretical but actually role assignment problems are just the kind of thing that can trip you up if you haven't thought through the implications and the context - and how to resolve that context to a specific person (or group) at that point in the process.?