Workflows

A workflow tracks a multi-step process — a contract review, an entity formation, an annual filing. Each one carries a checklist, assignments, due dates, and a complete history of who did what and when. Workflows attach to any record, so the process lives alongside the thing it’s about.

Lextree workflows track rather than enforce. They don’t force you to complete steps in order or block a status change until everything is checked. Instead, the activity history records every action, giving you an evidence trail of how the work happened.

Where you’ll find workflows

• On a record. Every record’s detail page has a Workflows section you can expand to start and track workflows for that record.
• In the Workflows activity view. Activity → Workflows lists every workflow you’re a participant in, across all modules. You can filter by status, due date, and module — and, like any list page, you can save that layout and export it to CSV.

Starting a workflow on a record

Creating an ad-hoc workflow requires Editor access to the record’s module.

1. Open the record and expand the Workflows section.
2. Click add (+) to start a new workflow.
3. Give it a name, an optional description, and an optional due date.
4. Add checklist items for the steps involved.
5. Assign the workflow or individual items to the people responsible.
6. Save.

Checklists, assignments, and due dates

• Checklist items are the steps. Check them off as work is done — in any order. Each item can carry its own assignee, a due-date offset, an optional description, and optional input fields for the assignee to fill in for that run only — these don’t become permanent fields on the record.
• Assignments associate people with the workflow or specific items.
• Due dates on a workflow or its items automatically create calendar events, so deadlines appear in the Calendar and trigger reminder notifications.

The activity history

You can edit the workflow record, but its activity stream is permanent. Every change — item checked, assignment added, status changed, comment posted — records the time and the person who made it. Removing a checklist item hides it from the current view but keeps its history in the stream.

Workflow templates

On Business and Enterprise plans, admins can define reusable processes as workflow templates in Settings → Workflow Templates. A template picks a record type and an outcome:

• Track checklist completion only — nothing is created or changed on a record.
• Create a new record — the workflow is the intake for a record that doesn’t exist yet, so it’s launched from the record type’s list page rather than from any existing record, and it’s visible to anyone with access to the module.
• Create a related record — runs on an existing record and produces a new record hanging off it.
• Update this record — completing the workflow changes the record it runs on.

Both creating outcomes can pre-fill values on the record they produce and carry the workflow’s files over to it.

Template-based workflows have an extra rule: starting one requires authorization on the template, not just Editor access to the module. Who can launch it is one of four settings — named people, anyone, all-access users, or members of chosen access groups. Who can be brought in as a participant is a separate setting, so a template can be open to launch while still restricting who joins the work.

Participants and requests

People assigned as workflow participants can open and work on a workflow even if they can’t otherwise access the parent record. This lets you bring in an approver or specialist for one process without granting broader access. Make the workflow self-contained by attaching the files and instructions they need. If you’re an Editor on the module a workflow’s record belongs to, you can join that workflow yourself, without waiting to be added — everyone else joins when an existing participant adds them. Guests never participate this way, whether by joining (guests are never editors) or by being added (they don’t appear in participant pickers); a guest who can see a record can still view its workflows read-only, like anyone else.

Requests — workflows launched from Request on a record type’s list page, or New Request on the Workflows activity view — have no parent record to inherit visibility from. Launching one is controlled by the template’s launch authorization; seeing the resulting request is a separate rule and still requires access to the module the workflow will create into. The person who launches it becomes its first participant, and once the workflow completes, the record it produces is shared under the normal rules.

Workflows vs. events

Use a workflow when someone needs to do something. Use an event when you just need a reminder on a date. A workflow with a due date gives you both — the task and the calendar reminder.

Who can see and edit workflows

• Viewing a workflow requires access to the record’s module (or being a participant).
• Creating or editing an ad-hoc workflow requires Editor access to that module.
• Starting a template-based workflow requires authorization on the template.

On Enterprise plans, access group scoping also applies to the records whose workflows you can see.