Teams

Keep document workflows
under shared ownership

Collaborate on templates, forms, and documents with shared workspaces, granular role permissions, and full audit logs for your entire team.

Start Free See Pricing

Free account, no credit card

Move from personal ownership to shared control

Create the ownership boundary

Move shared work into the organization. This includes templates, forms, files, keys, and integrations. Nothing should depend on a departing member's account.

Add people with a defined scope

Invite by email, then assign a named role at the organization, workspace, or team boundary. Pending invitations can be resent or revoked and do not become active seats until accepted.

Operate from shared resources

Run document workflows with shared templates, assets, and service identities. Access follows the granted role and scope rather than the identity of the original author.

Use organization, workspace, and team scopes deliberately

Nested scopes make it easy to manage permissions across departments, clients, and teams. Organizations control subscriptions and global policies, workspaces isolate business units, and teams manage project templates.

Use a workspace for a department, client, region, or other administrative boundary. Teams group the people and work inside it, and one member may belong to several. Labels, mixed resource listings, and organization search help people find work without changing its owner.

Choose role and scope together

A permission without scope is incomplete. Decide whether the role applies to the whole organization, one workspace, or selected teams, then check the operations that role permits inside that boundary.

Holds the organization-level ownership role. Transfer that responsibility before removing the last owner.

Teams can assign their own roles. Entitled plans can define custom roles and permission bundles. When groups nest, use the published inheritance rules to understand the effective access rather than inferring it from the visual tree.

Use guest or collaborator access for an agency, client, or reviewer who should see named resources without joining the internal workspace. Review the grant at project close and remove it explicitly instead of assuming inactivity removed access.

Separate internal seats from the audience receiving documents

Members and recipients are counted separately. An active member may use an included or paid seat. A person who submits a public form or only receives a generated document does not become an internal user.

Not an internal seat

Public form respondents, file recipients, and viewers do not join the organization when they interact with public output.

Pending invitation

An invitation does not become an active billable membership until acceptance. Resend, revoke, or allow it to expire without treating the recipient as an active user.

Suspended or removed member

Suspension, deprovisioning, and removal change active membership state and seat count under the billing contract. Confirm the change before relying on it for access removal.

Seat change preview

Preview how an invitation or activation changes the subscription before confirming it. Seats and render limits remain separate parts of the plan.

Guests and collaborators are billable by default and should be bounded to named resources. Render usage remains separate from people: one completed document uses one render regardless of its trigger, and paid plans start at $9 a month for 1,000 renders.

Answer the operational questions from account data

Who changed this?

Start with the audit trail when a result is disputed. It identifies who performed a covered action, what resource it affected, and when it happened. Filters and exports help narrow the investigation; selected alert rules can call attention to higher-risk events.

Who can see it outside?

Set the external-sharing rule above the individual resource. Named guest grants preserve intentional exceptions, while an access review exposes both inherited and direct reach.

Where did this template come from?

Import the resource types that are supported. Assign each one to its new scope. Test its credentials and integrations before production work moves to the new owner.

Is that automation a person?

No. A service identity is separate from a human membership. Give an unattended workflow scoped credentials and its own rotation and revocation lifecycle.

Who is spending the renders?

Usage and member or asset reports connect demand to account activity. Administrators get one place to investigate a change instead of asking each team for its own estimate.

Does it look like us?

Keep brand assets, sender identities, domains, and visual policy at the organization boundary so teams can start from the same approved resources.

Give IT the controls it needs to operate the account

Enterprise administration puts identity and access controls in one place. It also covers retention and integrations. Confirm the contracted controls and rollout sequence during security review.

SAML and OIDC single sign-on with verified domains
SSO optional or enforced, by domain or by group
More than one identity provider
Just-in-time user provisioning
SCIM provisioning and deprovisioning, groups included
Break-glass administrator recovery
Organization 2FA, session duration and reauthentication policy
Network and IP access policy
Central administration of forms, submissions, PDFs, captures, templates and assets
Central integration, API key, webhook and destination administration
Data retention, deletion and legal-hold controls when contracted
Contracted regional processing and storage options
Custom domain and subdomain controls
Support plan, escalation and SLA controls

Begin the rollout by verifying domains. Configure identity, provisioning, and access policy next. Import supported resources only after those boundaries are ready, then test the workflows that will carry production traffic.

Test with a small group before a broad launch. Check sign-in, new-user setup, group changes, and user removal. Keep the recovery account outside the normal sign-in path and limit who can use it. Record who owns each policy and who responds when an alert fires. These steps turn a list of controls into a process the team can repeat. They also give the security reviewer a clear path from identity policy to the resources it protects.

Make shared work easier to find than to rebuild

Personal memory stops working as the library grows. Labels and saved views help teammates find existing jobs. Search across the organization before creating another template to maintain.

Label resources and search across the organization instead of opening one folder at a time.
Use mixed resource listings when the job spans templates, forms, submissions, captures, and assets.
Save useful organization views so another member can return to the same filters.
Share a resource with the team that needs it instead of creating an unmanaged copy. Apply the same ownership discipline to forms and the integrations that move their output.
Import supported work into the organization. Check its new location before retiring the source.

Search improves reuse, but access rules still decide what appears. A missing result can mean the resource has another label, lives in another scope, or is not granted to the current member. Check those causes before creating a replacement. When a shared resource needs a new audience, change its grant deliberately and leave the original owner and history intact.

See people and render usage as separate costs

The people who use the organization and the documents it produces are different billing dimensions. Keeping them separate makes a proposed membership change and a higher render allowance easier to evaluate on their own.

Check the seat count before you invite or reactivate a member.
Track internal users apart from render limits and overage.
Use the plan and invoice breakdown to distinguish recurring user quantity from usage generated by document workflows.

The numbers are on the pricing page.

Match the subscription to people and production volume

Internal users and renders move independently. One completed document consumes one render whether it came from a form submission, connector, scheduled run, or direct API request.

A free account carries 50 renders a month with no card, enough to build the templates and inspect output before choosing a paid plan.
Paid plans start at $9 a month for 1,000 renders: that $9 plan covers 1,000 renders a month, 5 custom templates, and 5 GB of storage. Team administration arrives on Business, from $89 a month for 20,000 renders.
Adding a colleague does not change the render limit. Buying more renders does not add an internal user.
Automations use service identities and consume renders. People who receive their files do not become organization members.

This separation matters when the team and its workload grow at different speeds. A review group may add internal members while producing very little output. An automated billing workflow may increase output while the operations team stays the same size. Model both changes before purchase instead of forcing one activity into the price of the other.

Move existing work into shared ownership

Adoption often starts with templates and integrations tied to individual accounts. List that work first. Import a small group, test what it depends on, and repeat. Make the shared version authoritative only after those checks pass.

Choose an organization destination for each template, form, credential, and integration. Import them in small groups and verify each result.
Replace personal automation keys with shared machine identities. Give each one a clear scope, rotation schedule, owner, and revocation path.
Grant a contractor or client reviewer access only to the named resources required for the engagement.
An invitation that has been sent but not accepted is not billable, so a rollout can be planned ahead of the month it starts.
Seats are previewed before an invitation or an activation, so the bill for a change is visible first.
Internal user count and usage plan move independently: hiring two people does not oblige you to buy more renders.

Treat migration as a controlled handoff. Record the source and destination, compare a sample of imported resources, run a representative document, and confirm its delivery. Keep the old path available until the team accepts the result. Credentials deserve a separate check because copying a template does not prove that its data source, webhook, or storage destination is ready in the new scope.

Remove access without abandoning the work

A departure should change access, not erase the organization's history. Shared ownership keeps the account manageable while administrators review the person's access and transfer their duties.

Use the member directory and access review to identify current roles and scope.
Where you enable it, people request to join and wait for an administrator rather than being invited one at a time.
Suspend and later reactivate a member when temporary loss of access is more appropriate than permanent removal.
Organization resources remain after a member leaves. Transfer their duties and replace personal credentials before removal.
Payment failures follow the contracted dunning and retention lifecycle. Resolve billing notices before access or retention deadlines apply.
A plan transition keeps the account relationship in place. Review new quantities, rights, and move requirements before approval.

Finish by checking direct grants, group membership, active sessions, API credentials, and scheduled work associated with the person. Reassign ongoing duties before removing the final access path. The organization keeps the resource, but an integration can still fail if it depends on a personal credential that nobody replaced.

Use a checklist for every departure. Name the person who runs it. Set a due date. Ask the old team lead to confirm the new owner. Run one job after keys change. Then save the audit events with the offboarding record. A short, clear process is easier to repeat and easier to prove than a set of steps that only one administrator remembers.

Questions about team ownership and access

Who counts as a paid user?

An active internal member with a seat counts toward the organization user quantity. Anonymous form respondents, document recipients, and public viewers do not. Pending invitations are not billable, and suspended or removed members leave the active count according to the seat transition contract.

What happens to the work when someone leaves?

Shared resources remain after a member is suspended or removed. Before removing the last owner, give their duties to another member.

Can I see who changed what?

Audit events record the actor, action, target, and time for covered changes. Search, filter, and export them within the organization's retention policy. Alert rules can surface selected administrative and security events; they do not replace review of the underlying record.

Can I stop people sharing documents outside the company?

Organization policy can restrict external sharing and public links. Guests and collaborators can receive access to named resources rather than a whole workspace. Review inherited and direct grants before treating a resource as internal-only.

Does it work with our identity provider?

Enterprise controls include SAML and OIDC for verified domains. SSO can be optional or required. You can set up more than one provider, add users just in time, and manage users and groups through SCIM. Administrators also have a recovery path when the identity provider is down.

Do automations need their own seat?

Service identities are separate from human memberships and should use scoped credentials. Give each unattended integration its own machine identity. Set a rotation date and a clear way to revoke it instead of sharing a personal key.

Start generating documents
in minutes

Start Free

No credit card required.

Keep document workflows under shared ownership