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 / General datasource Sha...
Power Apps
Unanswered

General datasource Sharpoint Design Query

(1) ShareShare
ReportReport
Posted on by 1,257 Super User 2024 Season 1

Whenever I use sharepoint as a datasource I have only ever used text or number fields or date and people, lookups and choice I have always left to the powerapp end as was the general advice.    However with the introduction of modern controls I have noticed more people using sharepoint types such as look up or choice at source rather than just in the app.

 

Just wondering what the general consensus is on this? has the advice changed?

 

TIA

Categories:
  • Ami K Profile Picture
    15,689 Super User 2024 Season 1 on at

    Hi @vffdd - 

     

    As far as I am aware I do not think the advice has changed, but rather that you should be aware of the benefits and drawbacks of either option.

     

    With SharePoint, my preferred approach is to still control choices by the Power App and to update that choice into a Single Line Text column in SharePoint. This will accommodate scenarios when the Choice options inevitably change. Because the data in my apps connected to SharePoint are generally small in volume, it is easy to perform a bulk update of old choice values with new choices values (using Access or other some tool).

     

    In SharePoint, if a Choice option changes, SharePoint does not intelligently update any existing choice value with the new value - the old choice value will remain even if that choice has been deleted (unlike Dataverse, which intelligently updates existing data with the new Choice value).

     

    This also accommodates a scenario when you try to update a record which still contains an old choice value, but you receive a patch/submit form error because the Choice no longer exists.

     

    ------------------------------------------------------------------------------------------------------------------------------

     

     If I have answered your question, please mark your post as Solved.

    If you like my response, please give it a Thumbs Up.

  • mmollet Profile Picture
    3,187 on at

    @Amik said this about as well as you can I think. I see alot of people, if not most, using SP as their data source. I also see alot of people having issues with code due to complex column types in SP. I still only use text, number, or date column types to this day and have almost no issues with doing so. I have not tried them out with the new stuff in power apps yet but since it is so easy to do and control from a Power App I will more than likely continue to do it this way. 

  • vffdd Profile Picture
    1,257 Super User 2024 Season 1 on at

    ok thanks guys.  I understand with choice columns but I have a lot of cascading relatiionships.. Cat/SubCat/SubSubCat  and when adding these items in sharepoint it's so much easier to have a look up which auto pulls in the ID for the corresponding sub cat or sub sub cat.   As well as if I edit the name on the higher level say category it just automatically feeds down.. Just wondering are your thoughts still the same for lookups?

     

    thanks

  • mmollet Profile Picture
    3,187 on at

    On that topic I will step out as I have much less experience with cascading relationships like you are talking about. I just stick to doing it myself in the code and using intermediate tables as well as extra columns in the lists. This is just preference and if there was something that was easier and faster programatically then I would start to switch over for sure. 

     

    For example if I had a Department List that had Managers in it and then Managers had Employees under them (similar to what you have with SubSubCat) this is how I would set it up.

    Top level Department

    ID

    DepartmentName

    ETC...

     

    Manager Level (Level 2 or SubCat)

    ID

    DeptID

    FullName

    Shift

    Salary

    ETC

     

    Employee Level (Level 3 or SubSubCat)

    ID

    DeptID

    ManagerID

    FullName

    Shift

    HourlyRate

    ETC

     

    Then if I want to know the dept of an employee I simply do: LookUp(Departments, DepartmentName = ThisItem.DeptID) and im done. Basically lower levels store all IDs above them. Im sure you understood what was happening without me explaining it but figured a quick example couldnt hurt. 😋

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 July Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Power Apps

#1
11manish Profile Picture

11manish 411 Super User 2026 Season 2

#2
Mohsin Ali Profile Picture

Mohsin Ali 338

#3
WarrenBelz Profile Picture

WarrenBelz 256 Most Valuable Professional

Last 30 days Overall leaderboard