Every new project can start with its documents already in place. Using Ultimate Forms Actions, the moment a project is created in a SharePoint list, the system creates a department folder in the Documents library if one doesn't exist, creates a project folder inside it, copies the department's template documents into that folder, and links every copied document back to the project record. Four configured actions, no code, and no one ever again "sets up the project folder" by hand. This walkthrough builds the whole thing: the three-part structure, each action's configuration, and a worked example from project creation to linked documents.
The problem: project setup is copy-paste with a deadline
Most organizations run projects on documents that exist before the project does: the charter template, the risk register, the department checklist, the standard contract. So every project begins with the same ritual, someone creates a folder, hunts down the current templates, copies them over, and hopefully names everything consistently. It is unskilled work performed by skilled people, it happens at the busiest moment of the project, and it fails in quiet ways: an outdated template copied from the last project instead of the source, a folder named slightly differently, a document that never gets connected to the project record and becomes unfindable within a month.
The automation below removes the ritual entirely. Its deeper benefit is uniformity: when folder structure, naming, and linkage are produced by rules, every project looks the same, and everything downstream, search, reporting, audits, handovers, gets easier.
The structure: three lists, three roles
The design uses two document libraries and one list, each with a single clear job.
Templates library: the source of truth
The Templates library holds the pre-defined template documents, each tagged with a Department field. That tag is the routing key of the whole system: it determines which documents belong to which department's projects, and it means adding a new template to a department is a matter of uploading and tagging, with every future project picking it up automatically.
Projects list: the trigger
The Projects list carries the project information: Title (the project name) and Project Department, which matches the Department field in the Templates library and thereby selects the right templates. It also has a Documents Associated Items connection, so the copied documents appear inside the project's own form, no navigating to the library to see a project's files.
Documents library: the destination
The Documents library receives the copies, organized as {Department}/{Project Name}. Each document carries a Project lookup column pointing back to its project in the Projects list, which is what powers the Associated Items view above.
Structure in place, the automation is four actions, the first three triggered by project creation, the fourth by document arrival.
Step 1: Create the department folder
When a new project is created, the first action checks whether the department's folder exists in the Documents library and creates it if not, named {Project Department}. The existence check matters: the second RnD project must reuse the RnD folder, not fail trying to recreate it, and building the check into the action is what makes the automation safe to run on every project forever.
Step 2: Create the project folder inside it
The second action creates the project-specific folder within the department folder, following the {Department}/{Project Name} convention. Because the name comes from the project's Title column, the convention holds by construction; nobody can misname a folder they never create.
Step 3: Copy the templates in
The third action copies the relevant documents from the Templates library into the new project folder, selecting them by the project's chosen Department. This is the payoff action: the project is seconds old and already stocked with the current version of every template its department requires, fetched from the single source of truth rather than from whatever the last project happened to have.
Step 4: Link each document to its project
One more action completes the loop, this one on the Documents library rather than the Projects list: when a document is added, an Update list item action sets its Project lookup column from the folder name, which is the project title. Every document that lands in a project folder, the copied templates now and anything the team adds later, is automatically connected to its project record, and appears in the project form through the Associated Items connection.
.png)
This fourth action is easy to underrate. Without it you have organized folders; with it you have a relational system, where the project knows its documents and each document knows its project, in both directions, forever, without anyone tagging anything.
The example, end to end
A new project is entered in the Projects list: Project Name "Module X Development," Project Department "RnD." Three things happen in sequence.
The RnD folder is created in the Documents library (or found, if an earlier project already created it):
The project folder "Module X Development" is created beneath it:
The RnD templates are copied into RnD/Module X Development, and as each lands, its Project lookup is set:
Elapsed human effort: typing a project name and picking a department from a dropdown. Everything else was the system keeping its own rules.
Extending the pattern
The skeleton generalizes well beyond projects, and a few extensions suggest themselves immediately. Trigger on a status instead of creation, folders appear only when a project is Approved, by adding a condition to the actions. Add an alert so the project manager is notified the moment their document set is ready, with a link straight to the folder. Generate project-specific documents alongside the copied static ones, a charter pre-filled with the project's own data, using Word templates and print actions. And the same create-folder-copy-link pattern serves any entity that arrives with a standard document set: employee onboarding packs per role, client folders per engagement, audit binders per cycle, contract sets per vendor. Wherever "new X" is followed by the same document scramble, these four actions end it. For the broader relationship machinery connecting parents to their documents, see Create Relationships in SharePoint Forms.
The result is a document management workflow that runs itself: templates properly copied, folders properly named, every file linked to its project, and the team's attention on the content of projects rather than the logistics of their paperwork.
Frequently asked questions
Add your comment
