Is this a usage for Groups?

[Bill Dodson]

I am new here so please forgive me if I am posting this to the wrong place, or in the wrong way.  I just want to be accepted by the cool kids!

Anyway, some background and then the question.  We work on orders for customers that require a lot of communication.  There are specifications and tons of drawings. for each order.  Currently, we attach all of this to the order in our ERP system; Emails, PDFs, documents, spreadsheets and AutoCAD files mostly.  We keep these files basically forever, so in 5 or 10 years if new work needs to be done (we do buildings), we have the information we need.  We do about 1000 jobs a year.  Now, as I am sure you can you can imagine, these attachments become a mess.  With some people forgetting to attach important data, some not removing the old data before attaching the replacement data, and a host of other problems.

So my question: is this a good fit for O365 Groups?  My main concern is the sheer number of Groups we would create each year.  I would think a group per order would be best, but maybe a group per customer, as we have a fairly small customer base.  However, then, we would have fewer groups, but they would be massive, and have multiple jobs at a time.  Heck, I am not even 100% sure Groups is a fit for this.  Maybe I am a guy with a new hammer, and everything looks like a nail.

Any thoughts or pointers you have would be very welcome.  I would hate to create a monster that eats us up in the future.

[#2]

Bill yes this is the right place and a great question!

Groups might be a good fit to at least centrally store all the files generated with each order. I agree that one group per order might be too granular and perhaps you could as you mentioned have one group per customer and you could have subfolders per order for that same customer.

Since you know your use case/scenario best I would try to pilot a new order with that taxonomy, learn a ton and make a decision wether you want to expand this use case further.

[#3 · Accepted solution]

The 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-b...

If you're creating 1000 projects a year, you should be ok for the next 500 years ;)

[#4]

That should work. I plan to retire in the next 290 years or so.

[#5]

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.