Developer forum

Hi Jelle,
you can consider using the standard User destination provider functionality for that. There is an option called "Generate passwords for users" and "E-mail template", so once the imported user is new it will get a new generated password and it will then be sent to the users email. You can create muliple jobs, i.e. one job per imported language and have a condition for that language in the job mappings settings, then each job can have its own relevant email template with translated text for the used language.
The email template available tags to set are those:
"DWUsers:User:Username"
"DWUsers:User:Password"
"DWUsers:User:Name"
"DWUsers:User:Email"
"DWUsers:User:Country"

BR, Dmitrij

Hi Dmitrij,

Thanks a lot, this is really helpful. The multiple-jobs-per-language approach with its own template makes sense.

One thing we would like to check before we go this way: instead of sending the generated password in plain text, we would prefer the email to contain a link where the user sets their own password (a set-password / activation link). Looking at the available tags (Username, Password, Name, Email, Country), there does not seem to be a tag for that.

Is there a way to include a set-password / activation link in the template within this standard functionality, or is the generated password the only option here?

Thanks again,
Jelle

Hi Jelle,
Currently the UserDestinationProvider doesn't support a one-click activation/password-setting link as a template tag.
You can look on the solution proposed in this answer. 
You can include a static link to your site's Forgot Password page in your email template instead of showing the password. Something like:

Please set your password by visiting:
<a href="https://yoursite.com/Default.aspx?ID=YOURPAGEID">Click here to set your password</a>

You can pre-populate the username field by appending it to the URL:

/Default.aspx?ID=YOURPAGEID&Username=<!--@DWUsers:User:Username-->

This is a 2-step process for the end user (they still have to enter their email to get the link), but no plain-text password is exposed.
BR, Dmitrij 

Hi Dmitriy,

I'm picking up the work on Jelle's case about the automatic welcome email for new NAV-imported contacts.

I've set up the email template with the recovery link and prefill as you proposed, and deliberately left out the password tag so no plain-text password is shown. One thing I want to confirm is the trigger for the welcome email on the import: is it tied to the 'Generate passwords for users' option, or does it fire on its own when a new user is created?

My concern before testing: the staging environment has a large number of real users that don't have a password yet. Based on the option's description, enabling "Generate passwords for users" and running an import would also generate a password (and trigger the email) for those existing password-less users, not just genuinely new contacts. I want to avoid that.

I currently have Test mode enabled with my own mail address. I'm not sure whether this is enough to prevent the issue — does Test mode only reroute the outgoing emails to my address, or does it also stop the password generation itself from being applied to those existing users?

Two questions:

• What's the cleanest way to test the trigger without touching the existing password-less users?
• Is enabling "Generate passwords for users" the intended approach for the final live setup, given that we only want the recovery link and not the generated password itself?

Thanks in advance.
Kind regards, 
Wilfred Polderman

Hi Wilfred,

It fires for new users AND existing users who have no password (NULL or empty). So existing users who already have a password are safe — no new password is generated. Only users with NULL/empty passwords get a new one. The existing users in your case are found by the "Auto" feature using the search columns (AccessUserID, AccessUserUserName, AccessUserCustomerNumber, AccessUserEmail, AccessUserExternalId), so maybe you can choose just some one column that is unique PK column for the existing/new users to avoid other users updates.

The email sending uses the same guard, so emails only go out when a password was actually generated.

There is no "Test mode" in the UserProvider/UserDestinationWriter. Since existing users with a password are skipped, the real risk is only for password-less existing users on staging. Safe approach: Ensure staging users all have passwords set before running a test import, or
Run without the "Generate passwords" option first to verify mappings, then enable it once confident.

BR, Dmitrij