Flow Archetypes at ocity: a blueprint for modern professionals

Every team runs on flows—sequences of steps that turn an input into an outcome. But not all flows are alike. Some are straight lines, others are loops or branches. Over time, we have observed that most workflows in knowledge work fall into a small set of recurring shapes. We call these flow archetypes. Recognizing them helps you choose the right tooling, spot bottlenecks before they form, and communicate process structure without drawing a hundred boxes. This guide names the archetypes we see most often at ocity and gives you a vocabulary to talk about them with your team.

1. Where flow archetypes show up in real work

Flow archetypes are not academic categories. They appear in the everyday tools you already use. A support ticket system follows one shape; a code review pipeline follows another. When you open a pull request, you enter a sequential review flow. When you submit an expense report, you trigger an approval chain that may loop back if a manager rejects a line item. When you subscribe to a status update, you join a broadcast flow that pushes information to many readers at once.

Teams that ignore these shapes often end up with mismatched tools. They force a sequential approval process into a kanban board designed for parallel work, or they try to manage a broadcast notification with a shared spreadsheet. The friction feels like a tool problem, but the root is a flow architecture problem. Naming the archetype lets you ask better questions: Is this flow meant to converge or diverge? Does it need a single source of truth or a publish-subscribe channel? Should the next step wait for a human or can it proceed automatically?

In practice, most teams encounter four or five archetypes regularly. The sequential pipeline is the most familiar—each step depends on the previous one. The parallel fan-out splits work across multiple people and then merges results. The approval loop adds a gate that may reject and resubmit. The broadcast channel sends information one-to-many without expecting a reply. The state machine models a process that can be in one of several states, with transitions triggered by events. Each archetype has its own failure modes and maintenance costs. Recognizing them early saves time that would otherwise be spent debugging a process that was never designed for the work it carries.

Composite flows in the wild

Real workflows rarely fit a single archetype. A hiring process, for example, starts as a sequential pipeline (resume screen, phone screen, onsite interview), then fans out to multiple interviewers in parallel, then converges into a debrief meeting that may loop back for additional interviews. The value of naming archetypes is not to force everything into one box but to identify which pattern is dominant at each stage. When a process breaks, you can pinpoint which archetype is failing and adjust that segment without redesigning the whole thing.

2. Foundations readers often confuse

Two concepts frequently get tangled: flow and state. A flow is a sequence of actions that moves work forward. State is the condition of a work item at a given moment. A flow can change state, but the state itself is not the flow. For example, a bug report might be in "open," "in progress," or "resolved" states. The flow is the set of transitions that move it between those states—assigning, fixing, reviewing, deploying. Confusing the two leads teams to build state-tracking dashboards that show where items are but not how they got there or what happens next.

Another common confusion is between push and pull flows. In a push flow, the upstream step sends work to the next step when it is ready. In a pull flow, the downstream step requests work when it has capacity. Many teams default to push because it feels proactive, but push flows create work-in-progress buildup when downstream steps are slower than upstream. Pull flows, popularized by kanban, limit WIP and reduce handoff delays. The right choice depends on variability: if step times are predictable, push works fine; if they vary widely, pull prevents pileups.

A third confusion is between synchronous and asynchronous handoffs. Synchronous flows require both parties to be available at the same time—a phone call, a meeting. Asynchronous flows allow each party to work on their own schedule—email, a shared document, a ticket system. Teams often overuse synchronous flows because they feel faster, but they actually introduce scheduling delays and context switching. Asynchronous flows scale better, but they require clear documentation of what is expected and when.

Why these distinctions matter

When you start a new workflow project, the first question should not be which tool to use. It should be which archetype fits the work. If you confuse push with pull, you will select a tool that optimizes for the wrong behavior. If you confuse flow with state, you will build reports that show snapshots but not dynamics. Getting the foundation right saves weeks of rework later.

3. Patterns that usually work

Over time, certain combinations of archetype and context have proven reliable. Here are three patterns we see succeed consistently.

Sequential pipeline with explicit handoff criteria

When work must pass through a fixed order of steps—like content publishing (draft, review, approve, schedule)—a sequential pipeline works well if each step has clear entry and exit criteria. The key is to define what "done" means at each stage. Without that, reviewers re-review the same item multiple times because they are not sure what the previous step actually completed. Teams that write a short checklist for each handoff reduce rework by a large margin.

Parallel fan-out with a merge protocol

When multiple people need to contribute independently—like a design sprint where several designers explore different concepts—a parallel fan-out is efficient. The risk is that the merge step becomes a bottleneck or that contributions conflict. The pattern works when the merge step is lightweight: a single person compiles the results, or the team uses a shared template that forces consistent output. Avoid fan-out when the merge requires deep integration of each contribution; in that case, sequential or collaborative work may be better.

Approval loop with time-bound resubmission

Approval loops are notorious for stalling. The pattern works when the loop has a defined time limit and a clear resubmission path. For example, an expense report that is rejected should tell the submitter exactly what to fix and give them a deadline to resubmit. Without those constraints, items sit in limbo. Teams that add a "reject reason required" field and a 48-hour resubmission window see approval cycles shrink significantly.

4. Anti-patterns and why teams revert

Even when teams know the right archetype, they often fall into traps. Here are the most common anti-patterns we see.

Over-engineering a simple flow

A team with a straightforward request-response process—someone asks a question, someone answers it—decides to build a multi-stage workflow with statuses, escalations, and SLAs. The result is a system that requires more maintenance than the work it supports. The anti-pattern happens because teams want to appear organized, but they add complexity before they have data that justifies it. The fix is to start with the simplest archetype that works and add structure only when the volume or failure rate demands it.

Using a broadcast channel for a conversation

Broadcast flows are great for announcements but terrible for discussions. When a team posts a question in a company-wide channel, replies flood in from multiple people, often overlapping or contradicting. The original poster cannot track who said what. The anti-pattern occurs because broadcast channels are easy to create. The fix is to route discussion-oriented work to a thread or a dedicated channel with a smaller audience, and keep broadcast for one-way updates.

Treating all approvals as sequential

Many organizations require every approval to go through a chain of managers, even when the decision does not need all of them. This creates delays and demotivates employees who feel micromanaged. The anti-pattern persists because of habit and fear of liability. The fix is to classify approvals by risk: low-risk items can use a single approver or even a notification-only flow; high-risk items may need multiple sign-offs but can often be done in parallel rather than sequence.

Why teams revert to old patterns

Even after adopting a better archetype, teams sometimes slip back. The most common reason is tool friction. If the new flow requires extra clicks or manual data entry, people will bypass it. Another reason is lack of trust: if a manager does not believe the new flow catches errors, they will add manual checks that recreate the old sequential gate. Reversion is a signal that the flow design did not account for the social or tooling context. The solution is to involve the people who will use the flow in its design and to measure whether the new flow actually reduces cycle time or error rate.

5. Maintenance, drift, and long-term costs

Flows are not set-and-forget. Over time, they drift as the team, tools, and work change. A flow that worked for a team of five will break when the team grows to twenty. A flow that handled ten requests per day will clog at fifty. Maintenance is not just about fixing bugs; it is about periodically reviewing whether the archetype still fits.

Drift signals

Watch for these signs that a flow is drifting: people start using workarounds (email instead of the system), cycle times increase without a clear cause, or items get stuck at a particular step for no obvious reason. Another signal is that the flow has accumulated extra steps that no one remembers adding. A quarterly flow audit—a simple walk-through of the process with the team—can catch drift before it becomes a crisis.

Long-term costs of ignoring drift

The cost of a drifted flow is not just slower work. It is also lower morale: people feel like they are fighting the system. It is also higher error rates: when the flow no longer matches the work, steps get skipped or done out of order. Over months, the drift compounds until the flow becomes a liability. At that point, the team often abandons the system entirely and starts over, losing all the investment in tooling and training. Regular maintenance—small adjustments every few weeks—prevents the need for a full rebuild.

When to retire an archetype

Sometimes the best maintenance is to replace the archetype entirely. If a sequential pipeline has become a bottleneck because steps can now run in parallel, switch to a fan-out. If an approval loop is causing delays because most items are routine, switch to a notification-only flow with spot checks. Retiring an archetype is not a failure; it is a sign that the team has learned what works. The key is to make the switch deliberately, with a transition plan and a rollback option if the new archetype does not perform as expected.

6. When not to use this approach

Flow archetypes are a lens, not a prescription. There are situations where trying to fit work into a named pattern causes more harm than good.

Highly creative or exploratory work

When the goal is to discover something unknown—like a new product concept or a scientific hypothesis—imposing a rigid flow can stifle creativity. Exploration needs room for backtracking, serendipity, and nonlinear progress. In these contexts, a lightweight tracking system that records what was tried and what was learned is more useful than a step-by-step pipeline. Use flow archetypes only after the exploration phase has produced a repeatable process.

Very small teams or one-person operations

If you are a team of two, formalizing a flow with stages and handoffs may add overhead with little benefit. In small teams, communication is fast and informal. The cost of maintaining a flow system outweighs the gains. Wait until the team grows to at least five or six people, or until the volume of work makes it hard to keep track of what is happening.

Rapidly changing environments

In a startup or crisis response situation, the work changes so fast that any flow you design today will be obsolete next week. In those cases, invest in flexible tools that allow ad hoc flows rather than trying to standardize. A simple task list or a shared kanban board with minimal structure can adapt faster than a predefined workflow engine. Once the pace stabilizes, you can introduce archetypes to formalize the patterns that have emerged.

When the flow is a legal or regulatory requirement

Some flows are mandated by law—for example, a specific sequence of approvals for financial transactions or clinical trials. In those cases, you cannot choose an archetype; you must follow the prescribed process. The flow archetype framework can still help you understand the mandated flow and identify where it may conflict with your team's natural work patterns, but you should not try to redesign it without legal advice.

7. Open questions and common FAQs

Q: Can a flow have more than one archetype at the same time?
Yes. Composite flows are the norm. A single process might start as a sequential pipeline, then fan out, then converge, then loop back for approval. The archetype framework helps you label each segment so you can discuss and optimize them independently.

Q: How do I know which archetype to start with?
Look at the nature of the work. If each item must go through the same steps in the same order, start with sequential. If different items need different steps, consider a state machine. If the work is about broadcasting information, use a broadcast channel. If you are unsure, start with the simplest archetype that covers the majority of cases and add complexity only when needed.

Q: What if my team resists using a formal flow?
Resistance usually comes from a bad past experience with an over-engineered system. Start with a lightweight version—maybe just a shared list of steps with no tool enforcement—and let the team see the benefits before adding automation. Involve them in the design so they feel ownership.

Q: How often should I review my flows?
At least once per quarter for stable teams, and monthly for teams that are growing or changing rapidly. The review does not need to be long: a 30-minute walk-through with the team, looking at cycle times and workarounds, is enough to catch drift.

Q: Are there tools that automatically detect the archetype of a flow?
Some process mining tools can infer flow patterns from event logs, but they are expensive and require clean data. For most teams, manual observation and discussion are sufficient. The value of the archetype framework is conceptual, not computational.

8. Summary and next experiments

Flow archetypes give you a shared language to describe how work moves. They help you choose the right structure, spot problems early, and communicate with your team without drawing a new diagram every time. The key takeaways are: name the archetype before you pick the tool; expect composite flows; watch for drift; and know when to keep it simple.

Here are three experiments you can run this week:

1. Map one of your team's recurring processes. Write down the steps as you see them. Then label each step with an archetype (sequential, parallel, approval loop, broadcast, state machine). Look for mismatches—places where the archetype does not match the work.
2. Identify one anti-pattern. Pick a flow that feels frustrating. Ask whether it matches one of the anti-patterns listed above. If it does, propose one small change to move it toward a healthier archetype.
3. Run a 30-minute flow audit. Gather the team and walk through a process from start to finish. Note where work gets stuck, where people use workarounds, and where the flow has accumulated extra steps. Decide on one adjustment to test for two weeks.

Flow architecture is not about perfection. It is about making the implicit explicit so you can have better conversations about how work gets done. Start with one flow, name its archetype, and see what you learn.