Story templates are not story formulas

A character questionnaire offers a particular kind of satisfaction. Name, age, birthday, scar, childhood wound, favorite meal: one hundred prompts fill up, and the blank page finally looks defeated. Then the author returns to chapter one. The character still does not know what she wants in this scene, and she still has no choice she must make today.

That does not make templates useless. Templates are excellent at reducing the cost of beginning, reminding us what we have forgotten, and keeping recurring facts consistent. The trouble begins when three very different things all receive the name “template,” and one form is expected to manage information, shape a plot, and bring a character to life.

Before choosing a template in Scroll, separate the questions: Do you need a story formula, a content template, or a Project model?

A story formula guides development; a content template guides recording

Three-act structure, the hero’s journey, and beat sheets answer a developmental question: how might a story progress? They help authors think about turns, conflict, and rhythm. For some writers, a familiar method becomes a dependable creative language. Scroll’s content templates do not decide which narrative structure is correct, and an author who values a rigorous method can keep using it.

Character, location, organization, event, and writing templates answer a different question: when you create this kind of material, which information deserves a place to begin? A character card may need a current goal and position. An event may need dates, participants, and locations. A place may need hierarchy or coordinates. These are recording prompts, not instructions for act three.

A Project model goes further. Reusable properties, relationships, and visual structures give the Project a stable vocabulary for facts that need to be queried and compared. A mystery series might repeatedly distinguish evidence, possession, and time of disclosure. A fantasy series might need to check laws, costs, exceptions, and the regions where a rule applies. That is no longer one creation form. It is a way for the Project to express recurring meaning.

Once these jobs are separated, a template no longer has to perform work it cannot do. A character becomes convincing through desire, obstruction, action, and language. A structured record simply helps the author find the facts that must remain consistent later.

Begin with the smallest useful record

A restrained use of built-in templates is often the most useful way to begin a new Project.

For a character, record the immediate goal, position, and current state. For a location, begin with hierarchy and atmosphere, and add a precise position when the story needs one. For an event, capture dates, participants, location, and outcome. Fill the fields that you expect to search, filter, compare, or inspect through relationships.

Everything else can still exist. A character’s cadence, the physical awkwardness of a meeting, or the oppressive feeling of a town may belong in free-form notes and the manuscript. Turning every impression into a property does not make it more structured. It gives the author another field to maintain.

A practical test is simple: if information primarily needs to be read, let it remain prose. If it needs to be filtered, sorted, connected, or compared across cards, consider giving it structure.

Scroll’s Templates workspace includes Entity Templates, Event Templates, Relation Templates, and Writing Templates. Built-in templates and cards are included with Free, and the built-in template definitions cannot be edited. Free and Plus can create files from a custom template that already exists in the Project. Creating or editing Global or Project template, property, relationship, and visual-structure definitions requires Pro.

The product boundary carries a useful creative lesson: do not redesign every default structure before the first real character has moved through it. Let a small set of actual material reveal what the Project needs.

Cards and prose should reach one another without becoming the same thing

Long-form knowledge systems become heavy when every connection is expected to mean the same thing. In practice, a Project may contain at least three kinds of connection.

The first is a prose reference. A character’s name appears in chapter three, and a link can help the author return to the relevant card. This means the text mentions the character.

The second is a structured relationship. A character belongs to an organization, a person possesses a piece of evidence, or an event occurs at a location. These connections have relatively stable meanings and can support later inspection.

The third is an exploratory connection. On a Whiteboard, the author places a character beside a rumor to ask, “What if these are related?” A canvas connector can carry a hypothesis without becoming a confirmed fact in the story world.

Imagine that a journalist appears in the manuscript, has a confirmed professional relationship with city hall, and has also been dragged next to “forged testimony” on a speculative canvas. Those lines represent textual presence, established Story data, and a creative possibility. Keeping their meanings separate allows the author to explore freely without contaminating the facts that later chapters rely on.

This is another value of templates: not to force everything into a card, but to give stable facts a predictable home while keeping prose and speculation within reach.

When is a custom Project model worth creating?

Customization should not begin because a default template feels insufficiently unique. It should begin when a repeated problem has become expensive to inspect.

Consider a mystery series. In the first book, an ordinary event card records a ring being found. In the next case, a ledger moves through several hands. By the third, the author repeatedly needs to answer: When did this evidence exist? Who possessed it at each point? When was it disclosed, and to whom?

“Evidence—holder—disclosure time” now has three useful qualities. It recurs. It needs to be queried. Its meaning has become stable. The author can duplicate a suitable template, add the smallest necessary properties or relationships, and test them on a few cards. Spreadsheet, Relationship graph, and time views can then show whether the model actually makes the question easier to answer. After the experiment works, it may be worth expanding to older material.

Fantasy worldbuilding follows the same rule. “Magic law” does not require a new type merely because it sounds important. If every law must be checked against cost, region, and exceptions, structure may help. If one rule appears in one ritual, a precise paragraph may remain the better tool.

Before bulk modeling or metadata changes, back up the complete Project. A plan downgrade does not delete existing custom fields, but it can limit editing and migration operations that are no longer included. Current plan boundaries are documented in Plans and features and should be refreshed again before publication.

When should you wait?

Four signals suggest that customization is premature.

First, the need appears once. One ceremonial detail may not deserve an entire entity type.

Second, the field’s meaning is still moving. If “reliability” refers to narrator reliability today and evidence reliability tomorrow, a shared property will create confusion rather than order.

Third, the author is responding mainly to fear of omission. Anxiety readily grows fifty empty fields. Empty fields are neither story nor evidence.

Fourth, the information will not be searched, filtered, connected, or compared. When a detail needs occasional reading, prose is often cheaper to maintain.

The cost of over-modeling is not merely a busier interface. Every story change begins to ask which fields must change with it. The scaffolding becomes the building.

Test a proposed structure on a few real cards before expanding it. What remains should be a model that survived an actual writing workflow, not an elaborate system demanding maintenance before it has provided value.

Let a character card grow into the relationship the story needs

Return to the character questionnaire from the opening. A lighter path might begin with the built-in Character template, the protagonist’s current goal, and her public identity. The author creates city hall as a location and a public hearing as an event. During the hearing, the protagonist lies. At that point, the author discovers that “who knows this secret, and from when?” will affect many later chapters.

At first, that information can live in card content. As the circle of knowledge grows, the author confirms that it needs cross-character inspection. A small “knowledge state” property or relationship can be tested on a handful of cards: can a Spreadsheet filter the people who know, does the Relationship graph show the intended connections, and can a time view support the moment of disclosure?

The model grows after the story. The protagonist remains vivid because of the choice she makes at the hearing; the structure simply prevents chapter twelve from giving the secret to someone who never learned it.

Ask three questions before creating a custom structure: Does it recur? Does it need to be queried? Does it have a stable meaning? When all three answers are yes, it may belong in the model. When one answer is yes, leave it in prose for now.

The Templates workspace guide explains the public template types, and Custom Project model documents plan and migration boundaries. Continue to Why Does One Story Need 11 Views? when the harder question is how to inspect the records, or return to the Long-Form Writing Guide to choose a different path.

A useful template appears when it is needed and recedes when it is not. It leaves behind facts an author can trust—not an answer sheet the story must obey.