You can use a Query LDAP action to query for it.  Setup is below.  You can setup the samaccountname to equal a variable, then set that variable to a user's ID earlier in the workflow.   The property you want to grab is "info".  This is corresponds to the Notes in AD.  Depending on what other data is in the notes field you may have to do some further work after you get the notes to isolate the email.  

I'm struggling to pass the email address to the Variable vSiteEmail can you elaborate on the whole solution please? Out NOTES field only contain an email address so no need to trim etc.

The first info field should be all you need. If the second property is wrong it would overwrite the value in your variable.

Your query needs to be changed though.

{Common:Initiator} will always include the logon name in format DomainsAMAccountname

What you need is only the name without the Domain prefix.

You therefore should add a regular expression action before the query LDAP action that strips the domain name with this configuration

This will strip the domain prefix and leaves just the logon name. Use this in your query instead of common:initiator

Ok the expression is working fine but the email variable is still not working. I know this because I placed a test in the notification email that placed the values of the 2 variables at the bottom, the vSamAccount equalled the account used to initiate the workflow but without the domain prefix. The vSiteEmail variable was blank still!

The Query looks like so and appears after the expression:

The initiator account has a valid internal email address in the NOTES section in AD:

If you haven't tried this already, I would test it using the Run Now.  You'll need to enter an actual ID in place of the variable when you do that.  That way you can see if anything is coming back.  If you don't see anything being returned for "info", I would try another attribute, such as "givenName" to see if that returns.  If you're still getting nothing back, then it could be an access issue with the credentials you're using. 

Hi, its definitely not permissions. I did a RUN and manually entered the account name as you requested and the result came out as:

info (a line break)

      email@domain.co.uk

So the LDAP Is working. What I cannot fathom is that the variable is being stored correctly but appears to no be recognised in the LDAP query, I get this if I run with the variable:

The execution returned an unexpected error.
The (&(objectClass=user)(samaccountname={WorkflowVariable:vSamAccount}) search filter is invalid.

The vSamAccount variable is being outputted as the username minus the domain prefix.

Ok tested the whole workflow and this time manually entered the account name into the LDAP and it worked perfectly. This means the issue is with the variable in the created from the expression and then used in the LDAP

What is the variable type you are using for the vSamAccount?

Sorry, just marked as correct answer - I had a rogue bracket that was breaking the solution! Thanks for your answer