Disclaimer: Amateur programmer with no sharepoint experience

So looking through the questions here i came across the link below

Lookup between two lists programmatically

It looks like i can tie data from both lists but im not sure if i can tie multiple items on one list to a single item on another list.

This is what Im trying to do

For each project on the project list, I want the query to find the associated change tasks on another list and output to a custom view.

when a user adds a change task to a list, I do have an option to select the project it is associated with and it adds the project number to the change list giving me a column on each list to tie data together.

Would it be easier to query or make a relationship with the two lists column that has the project number?

1 Answer 1


I'll leave the back-end part of this response to those far more experienced. My specialty is with front end design combined with Nintex Workflow/Forms. My answer does not get directly to your question regarding preference to query or make a relationship. However, the list architecture of a sharepoint site, and thereby the solution you build, does have relevance. And since you spoke of having "no SharePoint experience" I thought I'd offer a crumb for consideration.

From a front-end point of view it's worth understanding the Lookup column in lists:

  • They support the ability to restrict behavior (prevent deletion of parent-child relationships)
  • By default you can have upto 12 lookups on a list to other lists (this can be increased)
  • List lookup columns are restricted to the same site.
  • From a UX perspective they're brilliant. They result in a hyperlink that opens in a dialog when pressed, and provide brilliant reference to relevant information.
  • From a manipulation perspective they store an ID and the name of the referenced item. This means they can be manipulated to great effect in workflow. I once built a no-code/workflow only master scheduler list for a construction company's approach to four different types of project build and used workflow to manage the automated build a project plan that tracked multi-checkbox lookup fields for Predecessors. Changing the dates on a task would cascade date changes all the way down the project plan. The client LOVED it.

As a side note, my experience is fairly deep with the front-end of SharePoint, and for nearly 10 years I've been building low-code/no-code solutions in SharePoint. I've even gotten an IT Excellence award in 2015 from the University of Alberta for a system used to assess the training of medical doctors. I don't claim to be the ultimate authority, but I do offer this suggestion. If you want to learn about developing SharePoint invest some time in learning how the front-end of SharePoint works. There are some limitations, but there are some outstanding possibilities in learning how to manipulate the front-end of SharePoint. This includes clients phoning me at 9am on launch day for a new version with a missed requirement in testing (their miss) to have that change implemented for a successful roll out by lunch time.

Programming in SharePoint will get what your client/business needs (most of the time). How long it takes to build and test is one thing. What the impact of changing the SharePoint stack is on upgrades to a future versions is another thing (I've heard of heinous horror stories of code slingers dropping such badly written code into a farm that it took nearly three years and a SharePoint Master to try and fix it - they still lost over 50% of their programmed functionality). But regardless of the myriad of opportunity you will only be well-served by learning how SharePoint works from the user's perspective when considering how to develop on the platform.

Best of luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.