Example of Using Admin Sets & Collections in conjunction

Admin set defines common workflow & visibility configs that effect all works in all collections (ETD workflow/visibility policy)
Collections define permissions for groups/users to be able to see/deposit works in each collection (one collection per department defining the users that can view/deposit to each collection)

...

Using your own use cases or ones we supply, design an approach and solution using the building blocks.

What's your biggest motivator on making customization decisions?

Worksheet:

What types of collections are needed beyond the predefined User Collections and Admin Sets?
- limits on who can create
- limits on discoverability (NOTE: can't control with an admin set)
- limits on other configurable settings (e.g. branding, nesting,
What admin set strategy is needed?
- multiple admin sets vs. just using the default
- do you need collection based permissions?
- one to one relationship between worktype and admin set? (customization)
What workflow strategy is needed?
- always use same workflow?
- need multiple workflows?
- need custom workflow?
What visibility strategy is needed?
- same visibility for all works?
- visibility policy based on legal access to works?
- visibility depending on type of work?
What worktype strategy is needed?
- How many distinct worktypes do you need and what are they?
- Will everyone need to use them or should some people be able to use certain worktypes? (customization)
- Will worktypes be defined by user needs or metadata needs or both?
- Or deposit only to certain admin sets or collections? (customization)
What relationship strategy is needed?
- Is nesting need?
- When will you use collections, parent/child, work/fileset relationships?
- Do you have metadata at the file level where child/nested works are needed or will you use filesets?
- How will performance be considered? (e.g. nested works vs filesets vs collections have different performance concerns)

Share back how you designed your repository

...