At its core, Control Center creates new items from templates and automatically provisions them when a new request is submitted through an intake sheet. Everything Control Center does is built around one central object called a blueprint, which is really just a set of templates plus the rules for how and when to turn those templates into a live project. Once you understand blueprints, the rest of the tool starts to make a lot more sense.
Here is how it works in practice.
A new request lands on your intake sheet. This can happen via a form, or (especially for projects) through the Smartsheet Salesforce Connector. You could do this through an API as well.
The intake sheet is more than a landing zone though, it also drives what Control Center calls "profile data." Profile data is the project information captured at intake (things like project name, client, budget, or start date) that gets automatically pushed into your provisioned templates so every project starts from the same accurate baseline. You decide, field by field, whether that data comes from the intake sheet, gets typed in manually during provisioning, or is set as a default value.
You can choose to trigger provisioning immediately, or only after an approval step. In Control Center, this is set up as an automation tied to a specific blueprint, you turn on "Automations," pick the blueprint, and from that point forward, marking a row as approved on the intake sheet is enough to kick off provisioning on its own. This gives you flexibility depending on how controlled your process needs to be, tightly gated approval chains for high risk projects, or a light touch, self serve flow for smaller requests.
One detail worth knowing early: if you run several project types (say, "Store Opening," "IT Project," "Customer Onboarding"), each type gets its own blueprint, and you can wire your intake sheet so a single column tells Control Center which blueprint to use for that row. That is what lets one intake sheet feed several very different project structures without anyone needing to know which blueprint sits behind the scenes.
Once approved, Control Center provisions a workspace or folder using your pre-built templates, which live together in what is called the blueprint source folder.
These templates can include anything you have set up in advance:
Templates are not all created equal though. When you build the blueprint, you mark each item as required or optional, and Control Center allows up to 90 templates per blueprint, so there is a lot of room to build a genuinely complete project kit, not just a couple of sheets. Optional templates are useful when only some projects need extra structure, for example a governance sheet that only kicks in above a certain budget threshold.
The powerful part is that the data captured in your intake sheet is automatically pushed into the newly created assets, using the profile data mapping you configured. This ensures consistency and removes manual setup work, nobody is retyping the client name into five different sheets by hand.
You also choose, at the blueprint level, whether each new project gets its own brand new workspace, or lands in a shared, preselected workspace. New workspaces are the right call when sharing permissions need to differ project by project. A shared workspace makes sense when everyone touching these projects should see all of them anyway.
| In this picture you can see an example of a workspace and inside this workspace, 2 folders, as well as a report, a sheet and a dashboard. |
After provisioning, Control Center can automatically add a row to a separate sheet, commonly called a summary sheet (or blueprint summary sheet). You choose which fields feed that row when you configure the blueprint, so the summary sheet only ever reflects the data you actually care about tracking at portfolio level.
In simple terms:
Your summary sheet becomes a high level portfolio view. However, for operational teams, it is often better to use reports built on top of the summary sheet, so each team only sees the columns relevant to them, rather than handing everyone the full, sprawling master view.
If your projects live in separate workspaces (which is common), there is a feature worth knowing about called dynamic report scope. Normally, when a report needs to pull from many project sheets, you have to manually add each new sheet to that report's scope as projects get created. Dynamic report scope removes that manual step, it automatically expands the report's "Where?" criteria as new projects are provisioned, so your cross portfolio reports stay current without anyone touching them. It is particularly useful for programs that provision a large number of projects into their own individual workspaces.
When projects are completed, Control Center can archive them. This step is not fully automatic, but it is quick, you typically just need a couple of clicks. Most teams handle archiving on a weekly basis.
Archived projects are not gone, they are frozen and moved out of the active view, which keeps your live portfolio clean while still letting you report on historical projects later for trend analysis or compliance purposes.
What happens after a blueprint has already been used to provision dozens or hundreds of projects, and you need to change the template itself?
Control Center gives you two ways deal with this situation:
Control Center also has a built in structure for who can manage a program versus who can simply use it:
That's the admin part of control center, but within you blueprint you also have 2 ways to manage permission
This scenario is best if you know how will own a project ahead of provisioning.
You can use this method to add managers or projects managers to a workspace, as long as you're happy with anyone in that group having the same level of access. What's powerful there is that you can customise the level of access on each item.
Control Center is extremely powerful, but setting it up can feel overwhelming at first.
A successful setup requires:
A couple of practical traps to know about in advance: renaming a template in the blueprint source folder without updating the blueprint builder means Control Center loses track of it, and global updates simply will not find the affected projects anymore. Likewise, editing a summary field directly instead of changing the underlying data will break the link between the two. Neither of these is obvious the first time you hit it, and both are avoidable once you know the rule.
If you want to learn more, you can check How We Automated the Entire Project Portfolio With Smartsheet Control Center.
Do you need help getting started?
If you have access to Control Center and want to automate your project creation but are not sure where to begin, I can help you design and build the whole setup.