Need an angle of attack for my first Sharepoint project

Question

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.

Answer 1

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.

Answer 2

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

• General: https://www.codeproject.com/Articles/1091804/Learn-SharePoint-step-by-step-in-hours-Hour
• Permissions: https://en.share-gate.com/blog/understanding-sharepoint-and-office365-permission-levels
• Useful for very specific things: https://icansharepoint.com

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!

Answer 3

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.