Sitecore DMS Engagement plans allow you to control some of the specific ways in which your website interacts and communicates with the visitors to your website. Think of engagement plans as a configurable flow state engine. It allows you to push the responsibility of automation to your customer.
Engagement plans are especially usefull when you have named visitors, ie users with a username and an email.
Engagement plans are controlled through the Sitecore.Analytics.Automation.VisitorManager class and the Sitecore.Analytics.Tracker class.
The Tracker class can be used for connecting a named user to the DMS visitor:
using Sitecore.Analytics;
using Sitecore.Analytics.Automation;
private void CheckAndSetTracker(string userName)
{
if (Tracker.IsActive)
{
Tracker.Visitor.ExternalUser = userName;
}
}
The userName is a fully qualified name, ie extranet\user.
To assign a user to an engagement plan, simply call VisitorManager.AddVisitor with the ID of the engagement plan state:
public bool AssignToEngagementPlan(User user, ID engagementPlanIdStartState)
{
bool addVisitor = VisitorManager.AddVisitor(user.Name, engagementPlanIdStartState);
return addVisitor;
}
The User is the Sitecore.User.
usually you would assign the user to the first step of your engagement plan, but you can in fact assign the user to any state you wish.
You can also move a visitor from one state to another:
VisitorManager.MoveVisitor(userName, source, destination);
You can also search for a specific user in an engagement plan to see is the user is alreay assigned to any state in that engagement plan:
private bool UserIsInAnyEngagementPlanState(string userName, ID engagementPlan, out ID stateId)
{
var result = false;
stateId = null;
foreach (Item state in GetEngagementPlanItem(engagementPlan).Children)
{
result = VisitorManager.GetStateVisitors(state.ID).Any(visitor => visitor.Equals(userName));
if (result)
{
stateId = state.ID;
break;
}
}
return result;
}
That’s basically it. It’s very easy to work with once you get the hang of it.
READ MORE:
- Sitecore Engagement Plan Cookbook.
- Sitecore Engagement Plans as an Audience Segmentation Tool by Mike Casey.
- Applying Advanced Sitecore DMS Capabilities: Engagement Automation by Aaron Branson, Roundedcube.
Brian Pedersen's Sitecore and .NET Blog 
Reblogged this on parablaxmi2002.
LikeLike
Do you know if there is a way to send an email using the current visitors email address if we don’t have a ‘User’ associated with the Visitor?
I want to use this functionality, but don’t want to create a user account for someone just because they entered their email address into a form – There might be thousands every month.
I know I can store the email address against the visitor by some other means (e.g. a separate database), but I’m not sure how you can then make that data available to choose in the “Send an email” action.
LikeLike
We use Web Forms for Marketeers for our forms. The form then creates the user, and triggers an engagement plan. The last step of the Engagement plan is a custom “Delete User” step, that (as the name implies) deletes the user.
Another approach would be to create your own step that sends an email without using Sitecore Email Campaign Manager.
LikeLike
Thank you. Your suggestions pointed me in the right direction to do some digging and led to some interesting findings.
It appears there is a pipeline called “findVisitorEmailAddress” which contains processors for obtaining the email address either from the user record or from a visitor tag of “email”. The strange thing is that the SendEmailMessageAction class well never start that pipeline unless the visitor has an associated username.
I’m going to see what I can do to override this default behaviour of SendEmailMessageAction so that I can make use of the ‘visitor tag’ method of getting the email address (or maybe another way entirely).
LikeLike
A quick update. Sitecore support confirmed that the behaviour I described above is a bug, and will be fixed in future releases.
LikeLike
Hi briancaos,
We have this model set for a while now, but I step on this line today with regards to the performance.
result = VisitorManager.GetStateVisitors(state.ID).Any(visitor => visitor.Equals(userName));
I feel that this could cause a major performance degrade. Any thoughts/ work around you can think of?
LikeLike
I am not sure how many visitors the VisitorManager will return. I guess it depends on how many users you have in the engagement plan.
I use a similar approach when unsubscribing users from an engagement plan:
private void UnsubscribeFromEngagementPlan(Item engagementPlan, IEnumerable userNames){
foreach (Item state in engagementPlan.Children)
{
foreach (var userName in userNames)
{
if (VisitorManager.GetStateVisitors(state.ID).Any(visitor => visitor.ToLowerInvariant().Equals(userName.ToLowerInvariant())))
{
VisitorManager.RemoveVisitor(userName, state.ID);
}
}
}
}
This works fairly well even in our 500.000 user environment, because the engagament plan does not contain a lot of users.
LikeLike