Forum Discussion
Is this a usage for Groups?
- Aug 19, 2016The use case is good. A project can use a Group and members will benefit from a central place to store files, notes, have conversations, set events in a shared calendar - among other Group experiences.
Your main limitation as you rightly identified will be the number of Groups you create. Each will have a SharePoint Site Collection for the files. There is a limit of the number of Site Collections you can create in SharePoint Online. It's a high number. 500,000 per tenant. https://support.office.com/en-us/article/SharePoint-Online-software-boundaries-and-limits-8f34ff47-b749-408b-abc0-b605e1f6d498
If you're creating 1000 projects a year, you should be ok for the next 500 years ;)
Hi Bill and welcome!
From my perspective, I'm seeing two big categories for the content associated with your jobs:
1) Content that is being actively worked on by the people associated with the job (In progress).
2) Content that is related to a job that was done a while ago, but folks may need to review for reference (Archive).
I find Groups to be most valuable when there is a specific topic/project where several people are actively working on developing or editing content. A big part of the reason is because in this scenario Group membership is always pretty clear, and so folks can self-administer their Groups without too much overhead. Your jobs that have content needs that are in progress may map well to this scenario. Aside from the administration piece, there are some other advantages that I've seen here:
Persistence: All the elements of producing and maintaining the content are self-contained in the Group and not dependent on individuals maintaining their own Calendar, Files, Tasks, Notes, etc. For the Groups I maintain, that means that if I have a change in a dedicated engineer or account manager, I can change the Group membership and not have to worry about engineer X's documents leaving when they are reassigned or the account manager's notes not being available. Everything built in the Group stays in the Group.
Integration with existing productivity tools: It’s easier for me to keep track of what’s going on across multiple Groups because the Group elements are natively available where I spend most of my time. When I’m in Outlook I can check Group Conversations/Calendars easily and when I’m in OneNote I can switch between Group notebooks easily.
Discoverability on Delve: Since the Group elements are connected to the Office Graph I can search across other Groups that I have permissions too. Searching for other documents and engineer I work with has produced is a good example of this.
All those benefits are may not be needed for content once it just needs to be archived for X years. So maybe a two-part process should be considered for testing:
- Building out a Group for each order while the job is in process.
- Having an archive process for Groups once the job is done to export any files to more of a long term content management system solution and then closing the Group.
That turned out to be a pretty long response, but I like the idea you had so I wanted to try and sketch it out bit.