1

I've been assigned the task to re-develop an existing intranet site in Sharepoint Enterprise 2016. I'm a competent desktop programmer, but I have minimal web development experience and no Sharepoint development experience. I was assigned this task because I'd already passed the necessary red tape to be able to work on other aspects of the contract, and my superiors don't feel like waiting months to find, hire, and vet a Sharepoint developer. In other words, I'm stuck with it, and I have to figure out how to make it work one way or another.

The intranet site is essentially a work log. It needs to be able to record log entries, each log entry must be associated with an assigned task in a many-to-one relationship (many log entries per task), and it needs to provide a UI to allow managers to view the tasks and drill-down to the associated log entries. From a pure database perspective this would be a piece of cake, but I have no idea how to implement it in Sharepoint. I don't want to use InfoPath or Access Web Apps, because those are both deprecated. The client will eventually want to add a lot of non-standard features that will almost certainly require custom code, so any approach that can't include future customization won't work either. Any guidance on the best way to begin development of this project would be greatly appreciated.

  • What SharePoint version are you working with? – Bernd Rickenberg Mar 11 '18 at 13:13
  • 2016 Enterprise. I suppose it would've been helpful to say that to begin with. – Shawn Elliott Mar 12 '18 at 3:07
2

Sounds to me like a simple SharePoint list is where you'd start. Very much like creating a database in SQL, set up your list columns for your required fields. Off the top of my head, you'd have a column for TASK (and set it up however you'd like - text box, drop down list choice, etc - whatever suits you best) to work with.

From there, you can set your FORMS (new, edit, view) for people to work with the entries. As far as customization of these fields, there's plenty of JS/JQuery solutions out there, depending on what you want. Mark Rackley provides a good starting point for some people as far as JS solutions in SP go. Google him.

  • 1
    Ahh, so when you create a Sharepoint List you aren't stuck editing the data in the raw table presented to you? You can create a form to allow user-friendly editing? That's good to know. (I'm not kidding when I say I know nothing about Sharepoint. Even the video tutorials assume more familiarity with the product than I have.) Can Sharepoint Lists be joined using foreign keys the way normal database tables can? – Shawn Elliott Mar 9 '18 at 22:39
  • No. SharePoint doesn't go as deep as PK/FK. You can import into a SP list from SQL, Excel, Access, etc. However, the fields must line up identically. One common solution is to create one master list, add to it via what I just mentioned above, and create separate views if you want certain people to see specific data. – DanJ Mar 11 '18 at 1:59
  • So I would have to store everything in a single flat table? Hmm. I'm not sure that's going to work. The log entries and task entries need to be stored in a many-to-one relationship, because eventually the task entries will have files attached to them as well. I suppose I could manually implement a PK/FK relationship between two separate lists. Not sure that's actually feasible in the long run, though. – Shawn Elliott Mar 12 '18 at 3:10
1

I recently started working with SharePoint and have found the following to be useful:

And the most important thing (especially for getting accurate assistance here) is to use this link to figure out exactly which version of SharePoint you are using!

Best of luck with your new project! We are always here to help!

  • Thanks for the links. I'll take a look at them and let you know if I have any further questions. – Shawn Elliott Mar 9 '18 at 22:42
0

Actually, SharePoint has OK support for relationships in lists. You can model 1-many and many-many relationships including cascading delete. Since you are working with tasks you could build your solution around two custom lists in SharePoint:

  • Log entry
  • Task list with a lookup column (single value) to the log entry list

You could use a standard SharePoint task list and extend it with the lookup column. Then users can synchronize the task list (except for the custom columns) via the ribbon with Outlook, which is a nice feature.

That said, you should be painfully aware of the restrictions that apply to this approach in SharePoint. Before SharePoint 2016 you could have a maximum of 5.000 items (without tweaking) in your lists. In SharePoint 2016 the limit is somewhat higher, but there is no absolute number. I think if you are looking at 20.000+ rows this approach is not going to work for you. There might be ways to work-around it, for instance if you can organize both lists into folders.

A completely different way to solve this is NOT to use SharePoint as data storage, but instead a SQL database or whatever you have at hand. You can nicely integrate into SharePoint by building a custom client-side web part, a SharePoint add-in or SharePoint Framework solution. Here you can chose by the tooling that is best for you and is good match for the complexity of the application.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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