Every team has one person who has figured out the automation. Their workflow is good. It saves real hours. It's wired up to their personal credentials, it runs from their account, and it lives in their head. Nobody else on the team uses it. Sometimes nobody else even knows it exists. When they change roles or leave, the playbook walks out with them.
This is the tribal-knowledge problem, applied to automation. A recent analysis found that 42% of institutional knowledge resides solely with individual employees and that more than 70% of process knowledge still lives in people's heads, emails, or spreadsheets. IDC pegs the cost of poor knowledge sharing at $31.5B per year. The personal-laptop automation is a small, daily version of the same failure.
Today General Input ships native sharing for workflows and credentials. This is what fixes it.
The reason workflows stay personal
Most automation tools were built around the individual builder. Each person sets up their own connections, builds their own workflows, troubleshoots their own runs. Sharing is usually a settings page nobody opens, or it's gated behind an enterprise tier. Best practices don't propagate, because the tool itself isn't shaped around a team. It's shaped around an account.
So the muscle memory becomes: build it on my machine, run it from my account, never hand it off. Even when somebody asks for help, the path of least resistance is to DM them an API key or screen-record the build. That's not knowledge transfer. That's a copy.
What sharing actually does
When you share a workflow with a teammate or your organization, the credentials that workflow depends on travel with it. The person you share with can run the automation, but they never see the underlying tokens. The credential stays owned by you.
At runtime, the executor's identity is what shows up in the audit trail. Their account is what triggered the run. But the OAuth token, the API key, the database password are injected into a sandboxed step at execution time and stripped before any payload reaches the AI. The model performing the work never sees a secret.
Practically, this means one person sets up the Salesforce connection once, builds a workflow on top of it, and the rest of the team uses it like an internal tool. If the person who built it leaves, the workflow keeps running. The automation belongs to the org, not to a laptop.
Why this is different from a template
General Input has had templates since launch. Templates are the bring-your-own-credential pattern: a workflow shape gets published, and each person who instantiates it plugs in their own connections. Useful when the automation is generic.
Sharing solves a different problem. Sharing is "use my setup." When the workflow is calling your CRM, with your permissions, on a schedule you defined, you don't want every teammate to also need their own admin credentials to your CRM. You want them to be able to run your automation. That's what sharing now does.
The credential invariant
There is one architectural rule worth calling out. A workflow's visibility cannot exceed the visibility of any credential it references. If a workflow uses a credential that's only shared with three people, the workflow itself can't be shared with the whole org. Sharing the workflow more broadly forces the underlying credential to be shared more broadly first.
This is the part most "team plan" features get wrong. They treat sharing as a permissions toggle on a workflow row and let the credentials lag behind, which is how you end up with broken executions for half the team. We modeled it the other way: the credential's visibility is the floor.
The real shift
The framing isn't really security, though that's there. The framing is institutional memory. The best automation on the team should not be one person's setup. It should be something the whole org runs, something that survives turnover, something a new hire can use on their first day.
If your best automation lives on one laptop, you don't have automation. You have a person.
Sharing is live on every plan today.