Features & settings
This page is for administrators. TaskFlow is modular — most capabilities are features you switch on — and this is where you manage them, along with instance-wide options.
Managing features
Admin → Plugins lists every feature with its source (built-in or added by you), its status — loaded, disabled, unavailable or failed — and a switch. Turning one on makes its pages, tabs and panels appear across the app; turning it off removes them and stops its background work within seconds. After changing the set, use Apply and reload so the interface picks up the change.
Features are off until you turn them on
A newly installed instance has its features disabled by default. Nothing loads, no background jobs run and no schedules fire until an administrator enables each one deliberately. If a feature you expect is missing, this is the first thing to check.
A feature can also show as unavailable: that means it isn't in the instance's allowlist and can't be enabled at all — see Configuration → Required in production.
The panel itself and the catalogue of every feature — what each one adds and where it appears once enabled — are on the Plugins page. A map of the whole administration section is in the overview.
Global settings
Admin → Settings holds instance-wide options:
- Default interface language — the language new users get. Anyone's personal choice overrides it.
- Configuration modules — lightweight switches applied to the running system in seconds: closed registration, password sign-in disabled, and single sign-on. The single sign-on toggle is always there, but only works together with the single sign-on feature being permitted by the instance configuration and enabled. See Users & permissions → Registration and Single sign-on.
- Attachment storage — which storage backend holds issue attachments (see File storage).
- System email — which transport carries password resets and other account mail (see Email).
- Danger zone — see below.
The danger zone
Wipe all data erases the instance's content and reseeds the defaults: projects, issues, boards, sprints, workflows, groups, permissions, the audit log, every feature's data and every user except you are deleted. Your account with its tokens, the system settings, the feature and config-module registries and the storage settings survive. The operation exists for demo instances and for handing over a fresh installation, and it asks you to type a confirmation phrase.
This destroys your data
There is no undo. The operation is unavailable unless it has been deliberately permitted in the instance configuration — on a production instance leave it switched off, so an administrator cannot wipe live data by accident. Take a backup before using it anywhere you care about.
Audit log
Admin → Audit records actions across the system: who did what, to which object, when. Filter by category, actor, action, object identifier, date range and full-text search over the entries.
Collection settings on the same page let you switch off recording for individual event domains; the list shows the domains events have already been collected for, under their technical names (core, users, acl, settings…). Narrowing this reduces noise and storage — but think twice before switching off security-related domains, since those are exactly the ones you'll want when investigating an incident.
AI & API control
TaskFlow can expose an MCP endpoint so external AI assistants work with your tracker. Admin → MCP controls it:
Service status, and the list of available tools marked read or write — administrative ones additionally marked configurator.
Kill-switches — three: a main one and two subordinate ones, available only while the endpoint is on:
- switch the endpoint off entirely;
- disable the write tools to leave read-only access;
- disable the administrative tools (the AI configurator) without touching everyday assistant use — see The AI configurator.
Changes apply within about ten seconds. Switching the endpoint off cuts off all connected assistants immediately; the other two switches merely narrow the set of available tools.
A call journal — who used which tool, when, with what result and how long it took.
Admin → API tokens is the instance-wide view of every personal token, with revocation. See AI & API access.
Automation, webhooks and notifications
- Automation (Admin → Automation) — rules that react to events, schedules or a manual run. See Automation.
- Inbound webhooks (Admin → Webhooks) — secret addresses external systems POST to: git hosting, a payment provider, telephony. What happens to a received event is decided by an automation rule. See Webhooks → Inbound.
- Outbound webhooks (Admin → Outbound calls) — send events to external systems, with a delivery log and a test button. Requests to internal network addresses are blocked, so a webhook can't be used to probe your infrastructure. See Webhooks → Outbound.
- Notification gateways (Admin → Notification gateways) — route notifications to an external system: a messenger, SMS or an automation tool. Each gateway has its own type, settings, event types and message templates per language; the Check button verifies the gateway's settings. This page also selects the transport for notification email and holds its templates.
- Messenger types (Admin → Notification gateways → Messenger types, the
messengersfeature) — gateways that deliver messages themselves, with no intermediary: Telegram (direct messages from a bot, or a chat), WhatsApp Cloud API, VK (from a community), MAX, Slack, Discord, Mattermost and Rocket.Chat via an incoming webhook, SMS via SMS.ru. The page is a reference for each type: what goes into the settings and what a person enters in their profile field. Any type can use a proxy (http,httpsorsocks5). Without this feature you still have webhook gateways, for example into n8n. - Secrets (Admin → Secrets) — tokens and passwords substituted into templates as
{{secret.NAME}}. The value is stored on the server and never sent back to the browser — it can only be entered again. The real value goes only into outgoing requests: the URL, headers and body of an automation webhook, the address and secret of a notification gateway. Everywhere else — comments, emails, logs, a dry run — it renders as***.
Notification email templates
The Email notification templates block on the same page sets the subject and body of the message for every event kind and every recipient language (Russian and English) — notifications arrive in the language from the recipient's profile, not the language of whoever triggered the event.
The event kinds are the same as for notifications: issue created, updated, assigned to you, status change, comment, mention and a due-date reminder. A template you haven't touched is marked default; an edited one is marked customized, and Reset to default puts it back. A change takes effect in about ten seconds — no restart involved.
The text is filled in from placeholders in double curly braces:
| Placeholder | Value |
|---|---|
{{event}} | The event name. |
{{issueKey}}, {{title}} | Issue key and title. |
{{fromStatus}}, {{toStatus}} | The statuses of a transition. |
{{comment}} | The comment text (first 200 characters). |
{{dueDate}}, {{daysUntil}}, {{dueLabel}}, {{dueStatus}} | The due date and how near or overdue it is. |
{{issueUrl}} | A link to the issue. |
The same set of names works in the message texts of notification gateways — one list for email and gateways alike, so a template moves between them without surprises.
The field itself lists the names
Type {{ in the subject or body and a list of placeholders with descriptions drops down; the braces button in the corner opens the same list with a search box. Below the field you get a breakdown of the template and a preview of the value.
The braces used to be single
Templates saved with single braces ({issueKey}) keep working — there is nothing to rewrite. New examples and the in-app reference show only the double form, the same as in automation substitutions. The sets of names differ, though: an email uses a short name ({{issueKey}}), a rule uses a path ({{issue.key}}), and a name from the wrong set resolves to an empty string.
Empty values leave no debris
A line that had placeholders and where all of them came out empty is dropped from the message entirely — no bare “Comment: ” arrives. If messages carry no link to the issue, the instance has no public address set — that is fixed at deployment, not in the template.
Email, storage and backups
Three areas have their own pages:
- Email — transports and which mail each one carries.
- File storage — where attachments and dumps live.
- Backups — schedules, retention and restore.
Import & archive
- Import (Admin → Import) — bring data in from Jira: users, groups, projects, issues, comments and attachments. The input is a pre-exported dump of the Jira REST API — files plus an attachments directory; the product never connects to Jira itself. Projects and field values are mapped, and validation runs locally before the run starts. It's a one-way import, not a sync, and cancelling doesn't undo what was already created.
- Data transfer (Admin → Data transfer) — moving data between two instances: export to files, import from files, or pulling straight over the network from the source instance (this needs its full-access API token). A transfer only adds and can be repeated without duplicates; issue keys are rewritten for the receiving projects. Transition history, passwords, permissions, plugin data, the audit log and settings are not transferred.
- Archive (Admin → Archive) — restore or permanently delete archived issues and projects, on separate tabs.
The archive works as a recycle bin
An archived issue or project disappears from everyday work: it is not in issue lists, on boards, in the backlog, in sprints, in the calendar, in search results or in Service Desk queues. The record itself is intact — it is visible in Admin → Archive, and from there you either restore it or delete it for good.
An issue can be archived from its own card, via a panel in the right-hand column. That is the reversible alternative to deletion, and usually the right one: deleting an issue cannot be undone, archiving can.
A few places deliberately do not hide the archive: opening an issue directly by link or key, sprint reports, logged time and CSAT ratings. Otherwise historical reports would change their numbers after the fact.
The Create menu
Admin → Create menu builds the Create dropdown in the top bar: entries with labels per language, an action (create a project, an issue or a board), a position, and visibility conditions by role, group or project. People only receive the entries that apply to them. An empty menu simply doesn't appear.
Changes are read when a page loads, so people see a reordered menu after a refresh.
Where to go next
- Administration overview — a map of every page.
- Plugins — the feature panel and what each feature adds.
- Users & permissions — accounts and access.
- Project configuration — types, workflow, fields.
- Self-hosting → Configuration — options set at deploy time.
See also
- Automation — the rules referred to above.
- Webhooks → Inbound — secret addresses for external systems, and the log of their calls.
- AI & API access → The AI configurator — what the administrative MCP circuit actually opens up.
- Single sign-on — the third config module on the settings page, and its providers.
- Search & notifications → Delivery channels — how the gateways configured here look to a user.