web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

News and Announcements icon
Community site session details

Community site session details

Session Id :
Power Platform Community / Forums / Power Apps / Considerations before ...
Power Apps
Unanswered

Considerations before using Dataverse

(1) ShareShare
ReportReport
Posted on by 174
Hello,
 
In the near future I'm going to be developing a HR app that I believe will need the row level security that Dataverse provides.
 
My question, I've been exclusively a Power Apps on top of SharePoint person, what should I be considering if I jump to Dataverse?
  • I know I've got a lot to learn about the security model for DV (Security concepts in Microsoft Dataverse - Power Platform | Microsoft Learn) it all seems so complicated.
  • I'll have to learn the differences in delegation 
  • I don't understand the DV capacity model so I don't know how long the app will be fruitful
  • I'll have to really start with an ERD
  • I think I have to build all the GUIs necessary (I don't think I am ready for Model Drive Apps)
What am I missing? 
I have the same question (0)
  • timl Profile Picture
    37,248 Super User 2026 Season 1 on at
     
    In addition to your list, some other things to consider (some of which are benefit) are:
     
    • Licensing
    • Environments/ALM/connection references
    • Dataverse data types - eg, Global/local choice lists, datetime column configuration  (local/timezone independent)
    • Dataverse calculated columns/rollup columns
    • Better offline capabilities
    • DV Backup/restore process 
    • Dataflows/data migration
     
    Delegation support is better with Dataverse, so you'll have fewer problems compared with SharePoint
     
    Building a canvas app GUI onto of Dataverse will be very similar to what you're used to. Although Vibe apps are still in preview, it may be GA by the time you develop your app and this would provide an easier  authoring experience. If you were ready for Model Driven Apps, Generative pages would offer a similar natural language design approach.
     
  • WarrenBelz Profile Picture
    156,003 Most Valuable Professional on at
    I will add a couple of things to @timl's summary
    • Dataverse is certainly a more robust and scalable data source
       
    • It has less Delegation restrictions than SharePoint, supports data source level relationships and has enhanced security (although you can achieve row-level security in SharePoint with Power Automate).
       
    • If licensing cost is a consideration, SharePoint will probably do the job (I have been using it almost exclusively for about 9 years across multiple customers on lists over 100k and have not found anything I could not achieve).
       
    • The two main items (if these are important to you) you miss out on with Dataverse are Person fields and the native SharePoint interface, which gives users a lot of control of queries/exports outside Power Apps.
     
    Please Does this answer your question if my post helped you solve your issue. This will help others find it more readily. It also closes the item. If the content was useful in other ways, please consider answering Yes to Was this reply helpful? or give it a Like
    Visit my blog
    Practical Power Apps    LinkedIn  
  • SebS Profile Picture
    4,848 Super User 2026 Season 1 on at

    Hi @FW-07051511-0

    Dataverse can feel intimidating at first when you come from SharePoint, but once you spend some time building with it, the security and relationship model starts to make much more sense. For the right solutions, it can become easier to manage than SharePoint.

    For an HR app, I would be careful about compromising the design to avoid premium licensing. In a medium or large organisation, the cost of poor access control, GDPR issues, missing audit history or exposing the wrong employee record can be much higher than the licence cost.

    @timl and @ have already covered some important points. A few things I would add:

    The biggest area is record ownership and security. You need to work out who owns each record, how HR, managers and employees get access, and whether you need owner teams, access teams, Entra group teams or business units.

    For example, a manager may need access to an absence case but should not see medical details, grievance notes or HR-only comments.

    Starting with an ERD is the right move, but spend time on relationship behaviour and cascading rules. Reassigning, sharing or deleting one record can affect related records depending on how the relationship is configured.

    For HR data, I would avoid hard deletion in most cases. Deactivation, retention and controlled access usually make more sense.

    Auditing also needs to be considered early. Decide which tables and columns need audit history, how long the organisation needs to keep it, and how much storage that may create over time.

    Watch the security context of Power Automate flows as well. A flow running under an account with broad permissions can bypass the user-facing security model and update records outside the access rules you designed.

    I would not dismiss model-driven apps too quickly either. A Canvas App may still be the right choice for employees and managers, but a model-driven app can save a lot of work for HR administration, case management, views, timelines and support.

    The ALM side also has a few Dataverse-specific behaviours worth understanding, especially Updates versus Upgrades, solution layers and partial deployments.

    Capacity is another area to check early, especially database storage, file storage, audit growth and attachments. For larger document volumes, SharePoint may still be the better place for the files, with Dataverse holding the case and metadata.

    I would build a small proof of concept first with an employee table, an HR case table, manager access, HR access, field security, auditing and deployment between environments.

    Once those pieces work, Dataverse becomes much less scary.

  • FW-07051511-0 Profile Picture
    174 on at
     
    These are all good points. Right now, the application purpose is to track two things; impact awards per person and telework time per person (limited to 30 days per year). So, I don't think GDPR or HIPAA or any of those considerations are necessary, but we know how things grow. 
     
    For the impact awards I need a way to collect nomination without the employee finding out until the nomination is approved and awarded. I will also experiment with templated certificates and DocuSign. The only attachment to the impact record will be the signed certificate weather if gets a wet signature and scanned in or it comes back from DocuSign, I just don't know yet. 
     
    For the telework, keeping track of requests, approval, and the number of days consumed between July and June (fiscal year). 
     
    I don't think ALM will be necessary but that will be another huge learning curve for me.
     
    I have no idea about capacity. With SPO it was easy to know if you were getting to threshold limits.
     
    I am really confused about the security model and @SebS made mention of teams and business units. I need to get my head wrapped around this.
     
    I will reconsider model driven app for the HR staff; I just have to get the creative juices flowing. 
     
    By the way the staff total size will be under 100 people.
  • SebS Profile Picture
    4,848 Super User 2026 Season 1 on at

    Hi 
     

    I think my enterprise brain went into overdrive the moment you said HR 😄

    Most of my background involves enterprise-scale applications handling absence records, medical information, disciplinary cases and other sensitive data. I heard “HR app” and went straight to the full Dataverse security model, teams, business units, auditing and retention.

    Now that you have explained the scope, I think Dataverse may be overkill for this.

    With fewer than 100 users and two straightforward processes, SharePoint should handle it without adding premium licence costs.

    I would use separate lists for impact awards and telework requests.

    For nominations, give users permission to create records and apply item-level permissions so they can only see their own submissions. HR and approvers can see all nominations. The nominated employee should not receive access until the award has been approved.

    For telework, users can see their own requests, while managers and HR see the records they need. Add a fiscal year column and index the employee, status and fiscal year fields from the start.

    I also would not bring DocuSign into this unless the certificate needs a formal electronic signature with a legal audit trail.

    For a normal recognition certificate, use an approved signature image, build the certificate as an HTML template and convert it to PDF. Run that through a separate flow after the award has been approved.

    Keeping document generation separate means the nomination and approval process stays simple. The app does not need to wait for the certificate to be created, and you avoid mixing several responsibilities into one large flow.

    You can then save the finished PDF in a restricted SharePoint document library and link it back to the award record. If someone signs a printed copy, HR can scan and replace or add the signed version later.

    Capacity should not cause you trouble at this scale. Even if each person uses all 30 telework days, you are only looking at around 3,000 records per year. SharePoint can handle that with indexed columns and filtered views.

    I would still keep a basic development and production setup, but I would not turn this into a large ALM exercise.

    Privacy and retention still apply because you are storing employee information, but the risk is much lower than the type of HR system I first had in mind.

    After hearing the full use case, I would stick with SharePoint and save Dataverse for when the application grows into something more relational or needs a stronger security model.

  • WarrenBelz Profile Picture
    156,003 Most Valuable Professional on at
    I totally agree with @SebS here. I have a couple of similar HR apps with the SharePoint Lists/Libraries containing everything from basic roles/authorities to personal family details, leave and sensitive documents such as renumeration and disiplinary letters.
     
    Within the authorites are codes of what the user can do - for instance a basic user is limited to their own records (and only parts of this), HR can see everything, team leaders can see certain parts belonging to their team members and managers can see these parts for everyone. I have a main SharePoint List and a couple of Libraries with linked in the ID of the main List. They have all worked as expected for a number of years.
     
    Please Does this answer your question if my post helped you solve your issue. This will help others find it more readily. It also closes the item. If the content was useful in other ways, please consider answering Yes to Was this reply helpful? or give it a Like
    Visit my blog
    Practical Power Apps    LinkedIn  
     
     
  • FW-07051511-0 Profile Picture
    174 on at
    @WarrenBelz

    How did you configure your security model across the list and document library so that it was automated? Do you use the HTTP request action to make line item security? What happens if a person's manager changes, how do you handle that?
  • FW-07051511-0 Profile Picture
    174 on at
     
    Would this small app be a good stepping off point to Dataverse instead of trying to boil the ocean when bigger HR needs arise?

    I wouldn't want to have to use an "enterprise app" for the first time in Dataverse.
     
    Thanks.
  • SebS Profile Picture
    4,848 Super User 2026 Season 1 on at

    Yes, I think this would be a good stepping stone into Dataverse. The scope is small enough to learn the platform without trying to build a full enterprise HR system on your first attempt.

    I would still keep the SharePoint design clean in case you decide to migrate later.

    If you create relationships between lists, I would avoid relying too heavily on SharePoint lookup columns. Use a separate stable identifier such as EmployeeKey, AwardID or TeleworkRequestID.

    You will often see people use the SharePoint item ID, but that value belongs to that specific list. A separate key gives you more control when exporting the data and importing it into Dataverse later.

    For example:

    • Employee list: EmployeeKey
    • Award list: EmployeeKey and AwardID
    • Telework list: EmployeeKey and TeleworkRequestID

    That creates simple logical relationships without tying the data too closely to SharePoint. When you move to Dataverse, you can export the lists, import the data and map those keys to proper Dataverse relationships.

    The Canvas App should also be manageable to move. You will need to update the data sources and some formulas because SharePoint and Dataverse handle items such as Choice, Person and lookup fields differently, but you should not need to rebuild the whole experience.

    You could then keep the Canvas App for the employee-facing experience and add a model-driven app for HR administration, bulk updates, views and record management.

    One important change will be security. Any filters you use in the Canvas App to control which records users see are only part of the user experience. In Dataverse, record access should come from security roles, ownership, teams and business units.

    So yes, starting with SharePoint is still reasonable, but designing the lists with migration in mind will make Dataverse much easier later.

  • WarrenBelz Profile Picture
    156,003 Most Valuable Professional on at
    My approach for the main items is a bit more low-tech than that - the two installations I have also have less than 100 employees and a central point of control.
     
    Each record of the control list (which everyone has view-only except key personnel) has the person and "reports to" in two fields as well as codes for various roles, (just a comma delimited string). At App OnStart, their email address their Managers email address and their Roles are set as Variables. Each function button/icon or control DisplayMode or Visible property then is controlled by what they are allowed to see/change. The more sensitive HR documents however are in a separate Library with permissions controlled there, so even if they manage to access SharePoint directly, they cannot access that Library.
     
    Please Does this answer your question if my post helped you solve your issue. This will help others find it more readily. It also closes the item. If the content was useful in other ways, please consider answering Yes to Was this reply helpful? or give it a Like
    Visit my blog
    Practical Power Apps    LinkedIn  
     
     

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Season of Sharing Community Challenge Winners!

Congratulations to our community stars!

Kudos to our 2025 Community Spotlight Honorees

Expanding mentorship, skilling, and AI innovation

Congratulations to the June Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Power Apps

#1
WarrenBelz Profile Picture

WarrenBelz 324 Most Valuable Professional

#2
11manish Profile Picture

11manish 193

#3
Valantis Profile Picture

Valantis 138

Last 30 days Overall leaderboard