Linc AIDocumentation

Settings Reference

Admin feature

Every settings tab at the Organization and Initiative scopes — General, About the organization, Departments, People, Interview Topics, Recording Methods, SOP templates, Brief, Assumptions, Deliverables, What Linc knows, and Members & Access.


Settings is organized into an Organization scope (org admins) and an Initiative scope (org admins and that Initiative's admins). Both live in the Account group of the sidebar: Admin opens organization settings, and Initiative Settings opens the selected Initiative's settings. Settings is for configuration only — running the interview programme lives in Discovery.

Text fields (the Brief, Company context, names, descriptions) save automatically as you edit — there's no Save button; a small "Saving…/Saved" indicator shows the status.

The tab list on the left stays in view while you scroll (on tablet-width screens and up) and scrolls on its own when it is taller than the window. Tabs that hold several things start with an On this tab line that jumps to each part.

Both scopes

  • General — At the organization scope: organization name, customer type, process diagram theme (Default or ARIS-style), logo (upload or remove), and SOP template customization (below). With an Initiative selected: rename the Initiative, edit its description, archive or restore it.
  • Members & Access — see the Members & Access section.

Organization scope

  • About the organization — what the company is and what it runs on, on one tab (older Company Context and Your Systems links open here). Company context is a shared, plain-language description of how the company works (mission, structure, systems, terminology, standards). Guiding questions help you start, or Generate draft from interviews drafts it from your people directory and completed interviews. Together with each department's context and people, it's given to Architect, the Scout interviewer, and Chat as background knowledge. Linc also keeps a separate, clearly-labeled "learned from interviews" layer up to date automatically as sessions complete — it sits beneath your written context and never overwrites it; depending on your org's setting, new learnings are injected automatically or wait for Review & publish. Your systems, further down, lists the software your organization already pays for, by product name ("Microsoft 365", "Salesforce"). Systems people named in interviews appear under Mentioned in your recordings as one-click suggestions. What these systems can already do is an AI-researched view of each platform's capabilities (click Research to generate). This is what lets Architect tell you an opportunity needs no new purchase — keeping the list accurate directly improves those recommendations. Put licence-tier detail ("we're on E3") in the company context.
  • Departments — add, edit, delete departments. Each can carry its own context (responsibilities, systems, roles, terminology) used as background knowledge. The In scope for column shows which Initiatives cover a department — click to tick or untick directly. Editing a department also shows its People panel (assign existing people, remove, or add new — a person belongs to one department at a time). A department's menu offers Best practices — an AI-researched view of how other organizations in that function have applied AI and automation, folded into Architect's opportunities as industry benchmarks.
  • People — the directory, the org-chart upload, job roles, and step requirements, on one tab. Upload org chart takes the spreadsheet HR already has (CSV or Excel, one row per person: Name, Job title, Department, optional Email, up to 400 people) and fills the directory, adds missing departments, and turns the job titles into job roles. The file is kept as an org-wide document in the Library, and the card reads Based on <file> · date · who so the directory's source is never a mystery; upload a newer one and it takes over. An On this tab line at the top jumps to People, Job roles, and What every step must answer. The list below is everyone Linc knows — members, past invitees, and people saved during planning — with coverage chips, an Edit button on each row (name, title, email, department, and notes), Add person, merge, and archive. With an Initiative selected, this same tab lists only people who belong to that Initiative: its members, and on the default Initiative everyone in the organization. The company directory, org-chart upload, job roles, and step requirements stay on Organization settings. Older Discovery → People links open this same tab. The summary chips above the list (total people, with an account, interviewed with a coverage percentage, awaiting a response, not contacted) each filter the list when clicked. The List / Map toggle switches to a view-only coverage map: your organization grouped into department boxes, each person a small card colored by status (green = interviewed, amber = invited, gray = not contacted), with per-department progress bars. When completed interviews surface new details about people, a banner says how many suggested updates are waiting — Review now opens them, each with the proposed text, its source quote, and Accept/Reject (text suggestions also offer Edit). Importing a process that names a person (a full name or an email — a job title or a team on a step does not count) adds to the same list. The directory changes only when you accept. The Organization overview at the top is a written summary of who does what, built from the directory, coverage, and process landscape — click Build overview (or Refresh) to write or rewrite it. A person's own page (hover a row and click the arrow, or find them in ⌘K search) opens outside Discovery. Back to people returns to this tab. The page shows their title, department, what they do, any proposed updates from completed interviews and imported processes (accept, edit, or reject them there), the responsibilities Linc mined from interview transcripts (each with its source quote), their interviews, and invitations sent to them. Job roles, further down the tab, are the jobs that do a step, such as Accounts Payable Clerk, so the same job is spelled the same way across processes. Each job has a name, optional other spellings (Also called), and an optional department. The Activities grid offers these when someone fills in who does the step, and marks anything outside the list with a small warning; a one-off can still be typed. A job is retired rather than deleted: it leaves the list but stays on the steps that already name it, shown with a "Retired" hint, and renaming a job never rewrites those steps (put the old name under Also called so it still counts). Below the list, Titles already written on steps gathers the who-does-this-step answers already on your processes, with live counts ("12 steps in 3 processes"), search, and paging. Add as a job role opens a small form, prefilled, where you confirm or edit the name — if it is a person's name, change it to their job — or skip it. Titles that already match a job (retired included) are labelled instead of offered again. Nothing on any step changes; the list only grows. Step requirements, at the bottom of the tab, are which questions every process step must answer: who does it (Responsible), what they need (Input), what they hand off (Output), which system they use (System), what record it leaves (Evidence), and whether a person or a system does the work (Manual / Automatic). All six are required until you untick some and click Save — this tab is the one exception to the page saving as you type (Cancel discards your changes, and Require all puts every question back straight away). Require nothing and every process reports 100% complete with nothing flagged. What you require is what the Activities grid on a process page highlights as missing, and what its % complete score is measured against. The questions themselves are fixed; only which ones are required is yours to choose.
  • Interview Topics (Scout group) — what Scout asks about during an interview. Set an organization base, then a department override or an initiative default.
  • Recording Methods (Scout group) — which capture methods people can use (live screen recording, video upload, document upload, meeting bot), with overrides per department, Initiative, or person. The most specific override wins, and methods are permissive unless restricted.
  • AI Governance — upload and activate policies (see the AI Governance section).
  • MCP Tokens (Developer group) — personal access tokens for external MCP clients (see the MCP section).

Initiative scope

Grouped into Initiative (what it is) and Analysis (how the AI works on it):

  • Departments in Scope — choose which departments this Initiative covers. The scope does two things: every department picker inside the Initiative offers only those departments (starting a recording, assigning one, moving a workflow or process), and Architect reads those departments' shared context as background during analysis. With nothing in scope, every department is available and Architect uses background from all of them.
  • Initiative default — the interview topics Scout uses for this Initiative, unless a single invite lists its own. It starts from the organization list. Org admins can also set these from Organization → Interview Topics, under Initiative defaults.
  • People — the people who belong to this Initiative: its members, and on the default Initiative everyone in the organization (they can open it without a separate membership). Someone from another organization who was added as a member still appears here, marked when they have no company profile yet. Each row shows name, title, and email; Edit changes a company profile (name, title, email when they don't have one yet, department, and notes). An Initiative owned by another organization says its people are managed there. The full company directory, org-chart upload, job roles, and step requirements are on Organization settings. Add or remove access from Members & Access.
  • Brief (Analysis) — the engagement brief injected into every analysis, opportunity, and roadmap: goals, inputs in scope, expected outputs, success criteria, company and industry context, systems, and additional instructions. Expected outputs also control which Architect tabs and stages run (e.g. Fit/Gap only runs when selected). The Include imported library processes switch (on by default) decides whether processes imported into the Processes library from existing documentation are analysed alongside interviews and uploaded documents; turn it off to analyse interviews and uploaded documents only. Create opportunities from industry-reference divergences (on by default) lets Architect turn Benchmark-tab divergences into Opportunities tagged as industry reference; turn it off to keep the comparison without those Opportunities. Keep recordings of the same process separate by (empty by default) names an axis — "person", "branch", "region" — along which recordings of one activity stay separate processes ("Requisition to PO — Amy Chen") instead of merging into one, for Initiatives whose point is to compare how a process varies. Recordings already merged can be split from the process detail in Architect.
  • Assumptions (Analysis) — the economic inputs behind every opportunity's savings figure: fully loaded hourly labor rate (with currency), working weeks per year, and automation efficacy. Left blank, they default to 52 weeks and 80% efficacy.
  • Deliverables (Analysis) — how outputs should be written: per-artifact format guidance (SOPs, BPMN, gap analysis, opportunities, to-be, roadmap, Fit/Gap) injected into the matching generator, and the Fit/Gap analysis instructions applied to every run (vendor context, target modules, system constraints).
  • What Linc knows (Analysis; org admins only) — a read-only view of the company context the AI reads for this Initiative, exactly as it is handed to Chat, Scout, Architect and the deliverable writers: the organization's description, the departments in scope with their people, and the Initiative's written documents, newest first. It also says how many documents it holds and, when there are too many to fit, how many of the oldest were left out of the block this time (they are still in the Library; the Learned from interviews document always stays in). Refresh rebuilds it. Nothing is edited here — change the inputs in About the organization, Departments, People or the Library.

The Initiative's written documents — the facts, decisions and corrections every analysis run reads (pasted replies, recorded question answers, chat saves, short text documents) — are not a settings tab: they are documents of the Initiative in the Library, listed under Documents with who added each and how, and added with Add → Upload or paste (see Processes). An older Settings → Business Context link opens the Library.

SOP templates

In General (organization scope), SOP templates control how generated SOPs look. The editor is one screen — an AI chat on the left and a live, editable preview on the right:

  • Chat: describe how the template should look ("match my uploaded sample", "use our brand colors for headings", "add a Safety section"). Upload your sample SOP (PDF up to 23MB, or Word .docx up to 30MB) and your logo here, then ask the AI to match it. A Word sample is read for structure only — upload a PDF when you want the styling matched exactly (in Word: File → Save As → PDF, then upload that file). The editor reminds you of this when you upload a Word document and marks a Word sample structure only.
  • Preview: everything is editable directly — each section's instructions inline, add/reorder/delete/toggle sections, edit the title, metadata fields, header, and footer, and turn on a background watermark of your logo.

Colors, logo, watermark, and section instructions are saved with the template and style generated SOPs; without customization, SOPs use the standard formatting. When regenerating an SOP, you can pick which template to use.

Each section's inline editor offers three kinds:

  • Written for each process (the default) — the AI writes the section from that process's sources, following the instruction you give it.
  • Process map slot — see below.
  • Same wording in every SOP — the text you type is the section, not an instruction about it, and it appears word for word in every generated SOP. Use it for standing text that describes how your organization works rather than any one process: an explanation of the BPMN notation you model in, a standard references or confidentiality block. Without it the AI has to write such a section from a process's sources — which never mention it — so it comes out worded differently every time, or as "Not documented in the sources".

A section can be a process map slot. Open a section's inline editor and choose Process map slot (or ask the chat for "a Process BPMN section that shows the diagram"): when an SOP is shown or exported in the template, the process's BPMN diagram is drawn into that section — in your organization's diagram theme — under whatever introduction the AI writes there. Sections titled "Process BPMN", "Flowchart" or "Process map" are treated as slots automatically. The standard sections include one (Decision Flowchart). When a template has a slot, the AI can also place flow fragments — crops of the map showing just the activities a step covers — after steps in the instructions, the way an ARIS-style procedure does. Fragments and the map appear in the template view and in the PDF and Word downloads; the plain Markdown view shows a note in their place.

New templates include an Activities section after the Procedure: the per-step attribute table (Responsible, Input, Output, System, Evidence, Manual / Automatic). On a process page this section is filled straight from the process's Activities grid rather than written by the AI; turn it off in your default template if you don't want the table in generated SOPs. Templates created before the section existed don't list it, and generated SOPs include the table unless you add the section and turn it off.