Forum Discussion
How to Organize Data
I am moving to sharepoint to manage my legal client case load. Currently I have an MS database where I store client data. From what I have read, a hub and spoke organization would be appropriate for me, the spokes being individual client cases. I want to make the client's "spoke" available to the client for viewing there data and for communication with me. I am confused though about the data now housed in the MS access DB gets organized. In one sense I can envision all the spokes simply being a collection of lists for that client, and they way I view all my client's data like I do now would be via the hub site. The other approach would be to just convert the access DB to dataverse, in which case, how exactly do I manage it within the sharepoint arrangement?
Hi standenman
To organize your data in SharePoint for managing your legal client case load, you can consider the following:
- Use a hub and spoke organization, where the hub site is the central point for managing client data and each client case is a separate site (spoke) within SharePoint.
- Configure permissions and access settings to make the client's spoke available for viewing their data and communication with you.
- You have two options for handling the data currently stored in the MS Access database: a. Convert the Access database to Dataverse and integrate it into SharePoint. b. Import the data from the Access database into SharePoint lists.
- Seek guidance from a SharePoint expert or IT professional to assess your needs and determine the best approach for your specific requirements.
Lalit Mohan your copying from ChatGPT hasn't actually answered anything, all it has done is to repeat what standenman was looking at anyway. An answer showing what YOU have done in the real world would be much more useful to the poster.
Rob
Los Gallardos
Intranet, SharePoint and Power Platform Manager (and classic 1967 Morris Traveller driver)
- Can you explain a bit more what kind of data, what requirement etc etc. Is it case by case basis ? Corporate or private clients etc.
NicolasKheirallah These are private clients. It is a "one off" business. One client one case and when we conclude the case we are done. There are several main areas of data: the obvious contact type data, along with past work data, and medical treatment data on the client. There would be some data that could pertain to all clients: doctor/clinic office data, medication data, and social security office data. In regard to this data, I am wondering whether I could simply use the same type of Internet API calls. For example, for Dr X, rather than storing all her data I could simply store her Npi code (https://npiregistry.cms.hhs.gov/api-page) or medications there are many databases of prescribed meds.
I am wondering at the client level, at their "spoke" could I just have lists on their data. That is, rather than having a central DB with all client data as I have now with MS Access, could I have a template spoke sharepoint site with all the lists I need in place, and simply populate client Xs lists via Microsoft forms?
But if I want from my hub site to see which clients I have that suffer from fibromyalgia, can I do that? The same function I have with MS Access queries.
A little confused about how to lay this out!
onestandenman the http actions (other than those for SharePoint) are premium actions so there would be an additional cost to be able to use them. As you will presumably already know the doctors' Npi codes you could get their data from the Npi site and store it in a SharePoint list. The all the client data could be added to several lists but would need to be ties together with some unique ID. The lists could be update via Microsoft Forms where you would enter the unique client ID. Overall I would probably not want to use Forms but to build it in Power Apps using the doctor Npi list and the client lists as the data sources. You could then have a screen that updates the data and adds new items to one or more of the client lists.
Rob
Los Gallardos
Intranet, SharePoint and Power Platform Manager (and classic 1967 Morris Traveller driver)
