Analytics.Tracker.Current is null in Sitecore 9 Update-1 Forms submit action with "Next" navigation step

Question

I'm trying to implement custom submit action in Sitecore 9 Forms according to the guide, but found the problem with Tracker.Current which is null while accessing from SubmitActionBase.

Tracker is fine in other areas (e.g. while accessing from view controller). If I call Tracker.StartTracking(); inside the action then Tracker.Current is ok as well.

Additional conditions:

• form is ajax enabled
• save action is called on "Next" navigation step, not on "Submit"

Is this expected behaviour in Forms submit action?

Here's part of the code:

public class UpdateContact : SubmitActionBase<UpdateContactData>
{
    public UpdateContact(ISubmitActionData submitActionData) : base(submitActionData)
    {
    }

    protected override bool Execute(UpdateContactData data, FormSubmitContext formSubmitContext)
    {
        //Tracker.Enabled is true
        //Sitecore.Context.Site.Tracking().EnableTracking is true
        //Tracker.IsActive is false
        var contact = Tracker.Current.Contact; //Tracker.Current is null
    }
}

Answer 1

I received feedback from Sitecore support:

The mentioned behavior is expected because the tracker should be only triggered upon a submit as it is expensive to keep it alive after navigating to the next or previous page

So it looks that it's not a bug. Tracker is not initialized in Forms "Next" or "Previous" navigation step. To workaround it, you can either change the form to non-ajax, or initialize the tracker inside your action code:

if (Tracker.Current == null && Tracker.Enabled)
{
    Tracker.StartTracking();
}
...
//access Tracker.Current

I checked this method and visits history looks fine.

Answer 2

You first need to identify contact and then you can use Tracker.Current.Contact notation. You need to use code from this article https://doc.sitecore.net/sitecore%20experience%20platform/digital%20marketing/sitecore%20forms/setting%20up%20and%20configuring/walkthrough%20creating%20a%20custom%20submit%20action%20that%20updates%20contact%20details and it's execute method. We had no issues implementing similar code in our solution recently.