Forum Discussion
Linking Sharepoint lists items across lists and 'Looking Up' columns
Hi,
Thank you for your response - it's much appreciated. The reason I didn't go for a single list is because I'm a relative novice when it comes to Sharepoint/Powerapps and honestly, I didn't realise you could have different forms derived from the same list - good to know though. I've no idea how to do that but I'll have a google later today.
The lists are really quite large - over 50 columns with entries being submitted by different people with different access restrictions - I need to ensure certain fields can only be updated by certain groups which is why multiple lists suited my needs although, considering what you mentioned below, I'm sure there may be a way around that using a single form. Your sharepoint knowledge vastly exceeds mine so hopefully I can work upto some of the workflow magic you mentioned below.
I've tried the 'unpretty' version you've mentioned below and I might just have to default to that. My only issue was that I couldn't figure out how to have 1 list view the same records across 2x different lists, because the entries are created uniquely (by flow) and aren't linked - but they do share some of the unique columns.
If Sharepoint list 1 has a Column titled - 'Job Number' and item 12345, flow then creates an entry and has that same unique column 'Job Number' and item - 12345, in Sharepoint 2 & 3 - is there some guide for how I can have Sharepoint 3 see the entry for 12345 from each of the 2x sharepoints from it's own item '12345' and pull data from both?
Thanks again for your help! :)
So you have multiple columns that exist as separate data values in multiple lists. Let's say we actually build this connection for Item 12345 that pulls in data from the other 2 lists based on the Flow copying the value "12345" to each of your lists. What happens when Item 12345 is accidentally edited to Item 1345?
Now lets do math. How many fields is Flow copying? Multiply by 3 lists? Multiply again by the number of list items and that is the number of potential data mismatches you have. The multiple list method may protect one or two fields from accidental or malicious changes, but only by putting your entire dataset is at risk.
In my experience, the "requirement" to restrict access to certain fields really masks a concern that some person who doesn't know what they're doing might accidentally change a value that breaks the process, such as assigning the wrong SME to a task. Do the 6-Sigma Why thing. Why do you need this requirement? Why do you have that concern? Why is it a problem if someone accidentally edits the wrong field? By doing that, I can usually get to the root cause/driver, such as "if the wrong SME is assigned, service delivery is delayed while we fix the assignment and X bad thing happens".
Now, that I've identified the actual need, I can usually find ways to address the concerns satisfactorily, such as "let's create a defined list of SMEs for each service so a user CAN'T pick the wrong one". The important thing is to help people understand how separate permissions on separate lists will actually make their problem worse. After all, they wouldn't have this "requirement" if they weren't concerned about dirty data in the first place.
Once we get past the separate lists, then there are things we can do that to guide users in the right direction and minimize their access to fields they shouldn't mess with. We can use views on pages to decide what fields they see. Carefully distributing fields across forms helps determine what fields they can access. Depending on the edits they need to make, quick edit can be a good option.
But the thing that will convince people they're data will be safe even if everyone can access all the fields is line item version control. Seriously, this will make you a ROCK STAR. Process owners will be able to see who made exactly what changes to which fields on which dates. And if a mistake was made, they can restore an earlier version of the item just like with documents. No harm, no foul. :-)
However, if multiple lists is an inflexible requirement and you risk getting fired for challenging it, then you're stuck with multiple lists and I would focus on lookups rather than copying data fields. At least then the data integrity is preserved.
- Mar 01, 2019Those are some very well crafted responses Rachel :). Totally agree.
Some notes. I gave up trying to rig SharePoint to do what I want. It’s so frustrating. I learned powerapps and my god it’s powerful and you can pretty much make any type of business app you want. I would suggest maybe looking more into it. I prefer Sql over SharePoint so I can use the app to handle security over all the data and columns etc. def. some ramp up time but it’s game changing.- Rachel_DavisMar 01, 2019Iron Contributor
I've used PowerApps for a few things and would love to leverage it more. Here's my problem:
- If I create a 3 screen canvas app for my list, it is formatted for mobile and replaces my native list experience. I can't give up the native list experience and all the filtering, grouping, column-formatting, etc. Sure, I can change the view back to the native list experience, but then I lose the PowerApp and I'm back to the default form.
- If I choose "Customize form", I get to keep my list experience, but the form only works on desktop. If anyone accesses the list via mobile or the SharePoint app such as from an email link, they get the default form.
No matter which one I choose, some of my users end up back at the default SharePoint form. At least with the default form I'm assured of a consistent experience regardless of platform or device.
Also, while I can handle basic Excel functions and I can copy/paste json to format a column. I'm not a coder. The whole formula based thing with PowerApps and when to select the card vs the field and how to write all those formula have been a real barrier for me. It's not easy or simple to pick up.
Lastly, I support over 500 sites across 5 business units. I have to be able to build something and hand it off to the process owner for ongoing care and feeding. If I build it in PowerApps, I'm gonna own it forever.