[PASSWORD ] not being sent with Welcome email

Sorry for the long delay in responding; I have been traveling for the past three days and in incommunicado.

OK, Here are the results of the test from your last suggestions:

Bingo! The Plans (User Email Confirmation:) were set to [No, override CB configuration]. Now set to CB Config and the Pending email is being sent! Progress!

However, the PASSWORD is still not being sent in the Pending email, re:

Dear Testing OneTwoThree;

Thank you for your application for membership in the (club).

Please log-in using the User ID test3 you chose and the password [PASSWORD] generated at registration.

Still just sending the Password tag just as it does with the Welcome email (I understand the Welcome email will not send the Password).

This has been tested with and without password generation and w/wo administrator approval. In each of the setting scenarios, the resulting email is the same (above).

Might there be some other obscure setting that I am missing?

I appreciate your persistence with this.

Please ensure the pending email is configured to be sent BEFORE payment. At any other point in time the password becomes encoded and would no longer substitute.

If I set the Plan User Email Confirmation: to [Yes, Before Payment], the password is now being sent with the Pending email. But, now they are not being presented with the payment plan until after first log-in.

Is that the way this is intended? It seems to me that this process delays payment and gives the user a chance to back out of the transaction, but their user registration information remains in the system if they do and creates additional administrative tasks. This work flow doesn't make sense from a user's or administrator's standpoint.

We've definitely made progress and you have solved the original issue (for which I am very grateful), but now a new issue complicates the registration process.

If I set the Plan User Email Confirmation: to [Yes, Before Payment], the password is now being sent with the Pending email. But, now they are not being presented with the payment plan until after first log-in.

This would be working as intended.

Is that the way this is intended? It seems to me that this process delays payment and gives the user a chance to back out of the transaction, but their user registration information remains in the system if they do and creates additional administrative tasks. This work flow doesn't make sense from a user's or administrator's standpoint.

Always always the registration is completed BEFORE CBSubs will do anything. This means if you try to send the password AFTER payment, which is far after the registration process then the password has already become encrypted and it's too late to send cleartext. You MUST send it BEFORE payment. This doesn't apply though when using random generated passwords as it will re-generate a password whenever necessary.

Another option is to simply use incubator project CB Emails to send the email (it handles cleartext passwords at the appropriate triggers) using the after registration trigger and the to address as

Kyle, thank you very much for this in-depth explanation of the inner workings of CB-CB Subs. I understand the process much better now.

I'll present these options to my client so they can choose which work-flow they would prefer.

Side note: It might be a big help to have a "Pre-Flight" checklist on all of the options available in CB and CB Subs. Juuust sayin'.

Thanks again, as usual, you've been a great help!

P.S. I did play around with CB Emails a bit as well, but not with the triggers you suggested. I'll give it a try.

Side note: It might be a big help to have a "Pre-Flight" checklist on all of the options available in CB and CB Subs. Juuust sayin'.

We've a couple workflows explained in the documentation, but there are just soo many to document with new workflows showing up sometimes daily or weekly as users find them. Very hard to predict every outcome with such a complex system. Hopefully when we've provided a better platform for offering documentation we'll be able to update it more and more often with new information.