Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2022 Release Wave 2Check out the latest updates and new features of Dynamics 365 released from October 2022 through March 2023
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
I am having a requirement from a client, he is asking to save a username/password in the contact record. Now, I know that if I am installing power portal, it'll save the same info in the contact record.
But, as there is no power portal here, I am doing it directly on CRM? does anyone has a better architecture to achieve this without breaking any security?? Though, the customer has it's own mobile app so they'll query CRM for verification.
instead of the password in plain text you should save a salted hashed of the password and use this value as authentication purposes.
Hope you are well and safe.
The entity attributes that are configured for field-level data encryption are listed in the following table.
Not recommended but salted hash as per Guido. Note: if you enter a password into a field in CRM and then hash it, make sure you exclude the field that data is being written into from the Audit History, and from memory I think you also want to do the Hash as a Pre Operation plugin (again trying to limit the exposure of the actual password value), and clear the actual password field.
Why its not recommended if Power Portal is using exactly the same architecture?
Not recommended as I am not recommending it but you can do it if you want, and even with the PowerApps Portal Microsoft prefer you not to use the Local Login and use Azure AD B2C or another identity provider instead (like google or facebook etc) - for these there is just a related record against the Contact that holds the identity provider and an identifier (no password hash etc).
Business Applications communities