Choosing Filevine projects in workflows
Project scope is set per-workflow, not at the credential level. Here's how to pick a Filevine project when you build a workflow.
When you connect a Filevine credential to VineMerge, that credential carries the same access your Filevine personal access token (PAT) already has across your Filevine org. There is no separate VineMerge-side project list to whitelist or block — VineMerge does not maintain a global "which projects can VineMerge see" setting.
Instead, project scope is decided per workflow, at the moment you set up a job.
Where project selection actually happens
Every Filevine-touching workflow — bulk update, scheduled document transfer, document exchange — starts with a short setup wizard. The first step picks which slice of Filevine this specific job will operate on. Other jobs you've run, or will run, are unaffected.
So if you're worried about "did I scope VineMerge correctly?" — the answer is that you scope each job, one at a time, when you build it. There's no upfront configuration to get wrong.
Walkthrough: scoping a bulk update
The bulk update wizard is the clearest example. When you click New bulk update, the first card is Select Integration, and it asks three questions in sequence:
- Integration. Which connected Filevine credential to use. If you've connected more than one PAT, pick the one whose access matches the work you're about to do.
- Organization. Filevine accounts can have multiple orgs under one user. Pick the org this job should target.
- Project Type. Filevine groups projects by type (for example, Personal Injury vs Workers' Comp). The job runs against one project type at a time, so VineMerge knows which sections and fields to expose in later steps.
The individual projects this job touches aren't picked from a dropdown — they come from the ID column in your CSV. Each row's project ID tells VineMerge which specific Filevine project that row's values should be written to. So your CSV is the project list. See Your first bulk update for how column mapping turns each row into a per-project update.
Document-exchange and scheduled-transfer workflows follow the same shape: integration first, organization second, then job-specific scoping. The pattern is consistent — pick the slice up top, supply the actual records as you go.
Running multiple jobs on different projects
Each workflow job is independent. Picking Org A / Personal Injury in one job doesn't restrict another job from targeting Org B / Workers' Comp, or even the same org with a different project type. You can run them in parallel. There's no shared "current project" state between jobs.
This is why the article you're reading exists: people coming from other tools sometimes expect a global "set the project context once" toggle. VineMerge doesn't work that way, and you don't need one.
Limiting access from the Filevine side
If your firm wants VineMerge to be unable to touch certain projects at all — not just unselected, but truly inaccessible — that constraint has to come from Filevine, not VineMerge.
The PAT you paste into VineMerge inherits the permissions of the Filevine user who issued it. So:
- Create (or use) a Filevine user whose role is restricted to the projects you want VineMerge to reach.
- Generate a PAT under that user.
- Connect that PAT to VineMerge as the credential.
VineMerge will then physically be unable to read or write projects outside that Filevine user's scope, regardless of which project type someone picks in a wizard. This is the right pattern for sensitive matters and audit-conscious firms.
Next step
Once your scope is set up the way you want it, learn how to keep it healthy: Test and rotate Filevine credentials.