AI OnAI Off
Member profiles: recommended approach
Hi Giuliano
Do your client have a CRM-platform in place? If not, they might want to consider implementing one for data like this.
Storing customer/member data in Episerver quickly gets out of hand and scales badly over time. I always prefer to have customer/member data in a customer-centric platform like a CRM. Then the CMS will just read and update the data there.
Authentication is different, and you can easily store and handle usernames/passwords with ASP.Net Identity, while using CRM for the rest.
Dec 29, 2020 11:59
Stefan Holm Olsen
- Dec 29, 2020 17:28
In that case you could try negotiating some kind of access to the CRM API. Maybe through a proxy API or something.
If you get the read access and still need to collect updates in batches, you could consider using Azure ServiceBus or Azure Queue Storage to store all the changes and flush them to the CRM at intervals.
If you get the read access and still need to collect updates in batches, you could consider using Azure ServiceBus or Azure Queue Storage to store all the changes and flush them to the CRM at intervals.
IMHO you should be working with claims instead of trying to create all these different properties per user in your scenario. UserManager has all the methods needed for getting, adding or removing claims for a user, much more flexible and also the way that all federated login works with claims so your UI parts might not need to change much if you switch to for example openid connect towards azure ad, Auth0 or similar.
Jan 04, 2021 12:25
For our current project (multiple sites, multiple stores, multiple roles, multiple types of users) we are asked to migrate data from an old cms into a fresh EPiServer build. Our EPiServer build is currently using asp.net identity & will contain "members portals" in the frontend where specific members can log in to update their information.
Each member "types" will contain a different set of properties following this pattern:
We are expecting to migrate 100k members with their related properties on day one & that number might possibly grow 10x in the following year.
I am confident asp.net identity will manage properties like email, password & username but I was hoping that I could use Identity to store & manage external properties (address, gender, etc.) but identity only allow one type of identity for the whole project. I don't want to use a single identity to store all the properties as it will not scale well / will be very difficult to read.
I was looking at DDS but the lack of relations between references (members) and their stores & the amount of data is not comforting me in this choice.
At this stage I am looking at the following options:
Profile store looks like a good fit for the job. I am reading the documentation at the moment and it contains a lot of information about tracking. While it is a nice bonus, I am worried that I might be choosing the wrong tool as I am just looking for a clean API to store users' properties.
Custom tables were suggested as a solution as I want to migrate, store and manage users' properties in EPiServer. While the migration might be fast (direct data-to-table approach), I am worried about cornering myself with this choice as I don't want to manage too many custom tables over time. I would also need to setup the cache layer myself.
Meta-classes and meta-fields look like a good option but the fact that it is part of an EPiServer Commerce solution means that I can't reuse this code/approach for the next project if Commerce is not included. We have clients who are interested by a "members portal" for their EPiServer build but they might be using a different ecommerce platform.
How do you store users information ? I am open to different solutions, I would love to know more about the trade-offs. Thank you.