<p>
        In the previous examples, you’ve seen that as local service events are raised, they are routed to the correct workflow instance. The magic that accomplishes this is the workflow instance ID that is passed with the ExternalDataEventArgs. The InstanceId property of ExternalDataEventArgs identifies the workflow instance that should receive the event.
        It is common for a workflow to wait for multiple events, using a different
        HandleExternalEventActivity instance to wait for each event. The standard event routing also handles this situation, passing the event to the correct HandleExternalEventActivity instance in the workflow. When one event is received, all other EventDrivenActivity branches are canceled.
        </p>
        <p>
        This type of event routing is sufficient for most situations. However, what happens if a workflow must handle multiple instances of the same event? This might be the case if the workflow includes an activity such as a ParallelActivity that permits multiple branches of execution. Each execution branch may be waiting for the same type of event. The standard event routing will identify the correct workflow instance, but how do you determine which activity should receive the event?
        </p>

        <p>
        The solution to this probelm is to manually control the event routing using a set of correlation attributes. These are attributes that you apply to the local service interface. They identify a prameter that is used to correlate an event back to the correct activity within a workflow
        </p>

        <pre data-sub="prettyprint:_">
        [ExternalDataExchange]
        [CorrelationParameter("branchId")]
        public interface ICorrelationExample
        {

        [CorrelationInitializer]
        void StartDemonstration(Int32 branchId);


        [CorrelationAlias("branchId", "e.BranchId")]
        event EventHandler<CorrelationExampleEventArgs> EventReceived;
        }

        </pre>