Skip to Main Content
Product Suggestions
Created by Alex Smith
Created on Mar 7, 2017

A new button in the CRM that sets a temporary e-login password for a user and automatically emails it to that user.

Beta Valve, since migrating to Prospect365 have encountered a problem with their current e-login setup.

They have some standard CRM documents that pulls through contact ID as the customer's password field and sends it to the customer as their temporary password.

 

Standard Document issues  

 

Online Account Activated 17 CR

  • This document currently pulls through the contact id no as the customers password field – this will no longer work with the new requested password format – (see below E login password issues for further details.)

 

Quote with login details  17

  • This document currently pulls through the contact id no as the customers password field – this will no longer work with the new requested password format – (see below E login password issues for further details.)

 

They usually use the CRM contact number to setup users up with an e-login password but have discovered 365 now asks for a password that must be 8 character minimum uses at least one capital, one lowercase and one number.

 

We've looked into changing the merge fields on their documents to pull the customer surname and contact ID in to the document and merge them together as one line of text as the temporary password. e.g. Smith12345.

 

We mentioned this to JB who recommended we log an idea to improve 365 as a whole in this scenario, as he anticipated that this will effect more and more customers as they migrate.

 

The system already has an in-built password generator, we think (it must do because if you do a I forgot my password request it sends you a new one. Might we be better off getting a new button in the CRM that sets a randomly generated temporary password for a user and automatically emails it to that user?

 

If we did that, we would also need a way of sending them in bulk.

 

From a security perspective, it would be critical to move away from this old version 6 methodology projects have previously employed to set passwords i.e. use Contact ID and a part of the contact name, via scripts - they've don’t that for many customers ecommerce projects in the past, but I'm sure that doesn’t meet ISO27001 requirements, because CRM or ProspectSoft staff could theoretically work out a password for a user.

 

We would be better of expending our efforts building a more secure password setup solution, perhaps in line with what other eCommerce solutions do, or the way Passpack generates random passwords, and building in a process of sending the temporary password, which perhaps expires within a date range, to new website users, rather than the v6 methodology and changing Beta Valves document/password issue process as per our initial suggested solution above.

  • ADMIN RESPONSE
    Mar 8, 2017

    Thank you for your feedback. This is something we have considered and would like to implement in the future.  We will review this along with other enhancements to agree where it will fix in the development pipeline. 

  • Attach files