Control Center Multi-Tier
I have struggled for a while with this and can't seem to get it figured out. My scenario is this, I have a group of employees (Account Executives) that have Accounts assigned to them. Each Account has a task list assigned to it.
Example below:
I have a project setup that involves a workspace and under that workspace, I want to separate my people that are using these projects. Under each person's folder, I have a location for all accounts and a folder for the task lists for each of those accounts.
Level 1: Account Executive Workspace
Level 2: {{Account Executive}}'s Accounts Folder
Level 3: All Accounts Sheet && Account Tasks Folder
Level 4: Account Task Sheets for each Account (Housed in Account Tasks)
Problem #1: I want to use Control Center to generate the overall folder for each Account Executive using an intake sheet that is housed in an admin location. Then I want to use the "All Accounts" sheet for each Account Executive as an intake for a child project in Control Center. The child project should generate the task list for each account as they are added. This would allow the Account Executives to add groups and have the task lists autogenerated within a seamless flow. (They wouldn't have to go to a separate intake sheet).
Problem #2: I would LOVE for the task lists to generate in the "Account Tasks" folder so that it doesn't feel so clunky when you have to move it into the folder manually.
Answers
-
Problem 1 is only partially doable with how SCC is set up, as we have a similar system in place. In our case we have 'Territories' which are really just geography-based teams, that have their own blueprint and intake sheet (we rarely add new ones, maybe 1-2x per year at most). We then have 'Requests' (which get provisioned into projects via another blueprint) with their own separate intake sheet that is shared among all Territories. The issue you will run into, is that for any given blueprint, it can only have one intake sheet. Meaning your child level projects all need to have a common intake sheet, although it can be different than the intake sheet for the executives.
We solved this problem initially by just filtering reports for each team off of the global intake sheet, which worked for about a year.. ended up that far too many people were writing formulas for ad-hoc reporting that referenced back to the intake sheet itself and it was causing the sheet to take so long to save that even the API would time out trying to add or modify rows. We moved to a Dynamic View instead which has worked a lot better once the users got used to the new UI and not having view access to the base sheet.
Depending on your number of users, plan, etc - you could probably use either of those options, or hack something together where you have a 'master' intake sheet that pulls in values from each of the child intake sheets and you use that master sheet as the SCC intake sheet. While this third option would work, I can't really say that I'd recommend it as it has the potential to get messy quickly.
For problem 2, if I understand what you're asking correctly, it would be to have a template that is provisioned land in a specific folder within a workspace, instead of the root of the workspace. Based on my understanding of SCC capabilities, this is not possible right now. Folders seem to be only partially implemented in a lot of places across Smartsheet and this is unfortunately one of them. My experience is that users will typically have to move the provisioned project folder/files at least once for organization's sake. I'll add here that you could solve that issue with some sort of API solution, either with MS Power Automate or a proper API app, but that's probably a bit outside the scope of this discussion... also likely not worth the development time for the value it would return.
-
@Brad Klodowski I agree with what you're saying, but it still isn't really a solution unfortunately. My problem with how this "Child" project deal is set up, is that it isn't really a child project. My assumption of a child project would be a project that is provisioned as a subproject of another project. It instead is more of an associated project. A project that is provisioned in the same workspace, but isn't necessarily tied in to the parent project in a significant way.
On #2, I have thought about using an API solution, but again, comes back to the same issue of it being called a "Child" project even though it isn't set inside of the parent project, like I would think a child project would be.
This system is just prohibiting us from having a seamless, nice process that everyone can enjoy.
The other thought that I've had is to set up a project for each Account Executive that looks at the account page instead of setting up child projects. But again, this isn't the ideal solution because I am trying to eliminate the need for us to have any set up outside of the initial Account Executive "Parent" project. I'm wanting a "set it up and let it roll" solution...
