Drupal chatbot module for Drupal 10 and 11 sites

Drupal occupies a specific slice of the web. The platform powers a disproportionate share of government portals, universities, research institutions, health authorities, large non-profits, and complex membership organizations — environments where content governance is strict, editorial workflows involve multiple roles, accessibility compliance is a hard requirement, and the site itself usually carries hundreds or thousands of structured content entries rather than a handful of brochure pages. A chatbot dropped into that environment has to respect the conventions Drupal teams already operate under. It needs to behave like a real module, not a rogue script; it needs to leave the theme and layout alone; it needs to coexist with Content Translation, Workbench, Paragraphs, Layout Builder, and whatever contrib stack the site depends on. Anything less than that gets refused during the first security review.

The Asyntai Drupal chatbot is packaged exactly as a Drupal module is expected to be packaged. The .info.yml file declares the name, the package (Chat), a configure route, and core_version_requirement for Drupal 10 and 11. The src/ directory holds the PHP classes behind the admin form and the controller responsible for the OAuth-style connect flow. A routing file defines the admin path; a permissions file restricts access to users with the appropriate capability; a libraries file attaches the widget CSS and JS as a proper asset library. A single configuration object stores the connected site identifier, which means the connection is exportable through configuration management, comparable in a staging-to-production deployment, and auditable through the same workflows the rest of your Drupal config passes through. Nothing about the module forces you to break the process you already use.

Installation lives inside the flows every Drupal administrator knows. The module folder goes under /modules/asyntai/ — or wherever your settings.php routes custom modules — alongside everything else contrib and custom. From the Extend page, a tick on the Asyntai row and the Install button resolves dependencies and enables the module. After that, Configuration → Web services → Asyntai AI Chatbot exposes the config form with a Get started button, which opens a popup to the Asyntai identity flow. You sign in to an existing Asyntai account or create a free one in the same popup, and the module records the connection into configuration storage. No API keys to paste between tabs; no hidden JavaScript in theme templates to find during the next redesign; no one-off customizations that a contractor will need to document for your successor.

Training the bot begins as soon as the connection is live. Asyntai walks the public URL space of your Drupal site the way a search engine would — home, department landing pages, program nodes, policy pages, article nodes, content type overviews, glossary entries — and builds a reference layer from what the crawler can render. For the subset of content that isn't on the public site (internal procurement guides, draft policy revisions, curriculum specifications that exist only as PDF attachments, HR handbooks, compliance manuals that live behind an intranet), you upload the material directly into the Asyntai dashboard, and the chatbot treats it as authoritative reference alongside the live crawl. Custom instructions, written in plain English rather than as templated prompts, shape how the bot answers: which contact to send users to for appeals, when to link to an intake form, which topics to refuse and defer to human staff, how formal or informal the tone should read.

Where Drupal really earns its reputation is in long, structured content — academic program descriptions, municipal service guides, benefit eligibility pages, research outputs, legal disclosures. Visitors struggle with that content because it's deep, hierarchical, and written for regulators as much as for end users. The chatbot cuts through that by letting someone simply ask: "Am I eligible to apply for this program?" "What's the deadline for the fall intake?" "Which department handles appeals for a denied application?" "Do I need the certification before enrolling or after?" Behind the scenes, the answer is pulled from the exact node the regulator approved, without the visitor needing to locate the page, scroll through it, and interpret the legal language. That reduces the load on generic contact forms and redirects the email volume your staff spends time on — without giving the visitor a templated, hollow response.

Multilingual coverage deserves a separate mention because Drupal's multilingual story is already one of the strongest in the CMS landscape, and the chatbot complements it rather than duplicating it. Your Drupal site may publish content across four, five, or ten languages through Content Translation. The Asyntai widget itself localizes its UI into 36 languages, and the AI detects each visitor's language from the first message they send. That means a Croatian citizen landing on the English version of a ministry portal can type in Croatian and get a Croatian reply, grounded in the English source content, without your content team ever creating a Croatian translation. The reverse works too — a French reader on the Arabic site gets French answers. For international universities, global non-profits, and governments with constitutional multilingual obligations, this fills the long tail of language demand that manual translation budgets can't justify.

Accessibility and compliance matter more on Drupal than on most stacks because of who runs Drupal. The widget ships with keyboard navigation, a visible focus ring, screen-reader-friendly announcements for new messages, and contrast-aware color choices that work across common institutional themes. It doesn't inject modal overlays on page load, doesn't block interaction with the underlying page, and doesn't hijack the keyboard when the user tabs through your site. If your organization is subject to WCAG 2.1 AA, Section 508, or the EU Web Accessibility Directive, the chatbot widget behaves in a way that's defensible under a procurement review — not as a guarantee of certification, but as a component that won't single-handedly fail the audit.

User Context is the feature Drupal teams reach for once the basic rollout works. Many Drupal sites have authenticated areas — a member portal for a professional association, a student section for an institution, a case-tracking page for a municipal service. In those sections, the anonymous chatbot experience isn't enough. You want a logged-in user to be greeted with answers that reflect what the site already knows about them. On Standard and Pro plans, your theme or a small helper module injects a window.Asyntai.userContext object before the widget loads, populated from $account->getDisplayName(), custom profile fields, role attributes, or whatever structured data your Drupal install carries for the current user. The chatbot then treats that data as part of the prompt and answers accordingly. "What's my next renewal date?" "When does my membership expire?" "What's the status of my grant application?" — the bot has the minimum context it needs without any direct access to Drupal's database.

Multi-site is a frequent Drupal pattern and the chatbot handles it naturally. A higher-education institution running a shared Drupal codebase with separate faculty, research institute, and alumni sites can connect each of those sites to its own chatbot with its own training, its own custom instructions, and its own branded widget. A federal agency running a portfolio of program-specific Drupal sites under one code repository can do the same — each program gets a dedicated bot, trained on the narrow content set it owns, capped at its own plan level. Plan tiers scale with deployment size: one site on Free, two on Starter, three on Standard, and up to ten on Pro. Agencies and digital partners running Drupal for multiple clients can consolidate those clients under a Pro plan and still keep each chatbot properly isolated.

Lead capture has a different shape on Drupal than on a consumer e-commerce site. Drupal inquiries tend to be higher-value and lower-volume: a prospective student asking about a doctoral program, a business filing a pre-tender question, a citizen seeking guidance on a benefit appeal, a donor requesting information about a capital campaign. When the bot can't resolve one of those itself, it captures the visitor's email (and any relevant detail the conversation surfaced), stores the full transcript in your Asyntai dashboard, and optionally emails the transcript to a mailbox of your choice. The pattern a lot of Drupal teams converge on is routing that notification into an existing Webform-driven intake or a shared department inbox — the chatbot does the first-pass triage, and the existing Drupal workflow takes over from there.

Insight from the dashboard is the part Drupal editors tend to underestimate until they actually look at it. Every conversation is logged and searchable, tagged by topic, detected language, and frequency of appearance. Editorial teams using this data discover the gaps between how staff write content and how visitors ask about it: the program page that never uses the word "tuition" even though half the questions about it do; the benefit eligibility node that's technically correct but phrased in a way no actual claimant would find through search; the policy update the communications team quietly shipped three weeks ago that turns out to confuse every reader who hits it. Over a quarter or two, those patterns turn into a concrete content-improvement backlog, grounded in real visitor language rather than editor guesswork.

The Drupal organizations that get the most from this chatbot tend to share a profile. Government portals handling high-volume citizen questions on eligibility, deadlines, forms, and contact paths. Universities and colleges running admissions, advising, and student-service information at scale across long content trees. Research institutions fielding repetitive questions from external partners, press, and prospective collaborators. Large non-profits and NGOs where an understaffed communications team is the single bottleneck between a well-funded programme and the people it's trying to reach. Membership associations running gated portals where members want account-aware answers. Public hospitals and health authorities serving patients through structured service directories. In each of these, the shared pattern is large content, long tails of visitor questions, and a human team too small to answer every inquiry personally.

Rolling this out doesn't require a platform redesign or a new editorial workflow. Install the Drupal chatbot module, enable it under Extend, connect it through Configuration, let the crawler index the public site, upload the internal reference material that isn't on public nodes, write a handful of custom instructions that codify how your organization communicates, and flip it live. Your Drupal content editors keep writing and publishing the way they always have. Your site's theme, layout, blocks, views, and translation workflows continue to behave exactly as they did before. The chatbot slots in as a quiet layer on top of all of that, carrying the visitor-facing conversation load your staff was never going to have time for.