34b927ff23
## Summary - **Public domains can now be bound to a specific app.** When a request hits an app-bound public domain, route resolution restricts logic-function matching to that app's HTTP-routed functions only — isolating each app's routes to its own domain instead of letting routes from other apps in the workspace match nondeterministically. - **Settings sidebar reorganized.** Removed the standalone Domains page. Workspace Domain → General. Approved Domains + Invitations → Members "Access" tab. Emailing Domains + Public Domains → Apps "Developer" tab. Roles → Members "Roles" tab. ## Why The use case: someone building a partner portal app or a lead-collection app declares private objects (leads, partners…) plus a few public HTTP routes. Each app needs its own domain (`partners.acme.com`, `leads.acme.com`) without those domains exposing every other app's routes in the same workspace. Today's PublicDomainEntity is workspace-scoped only, so all HTTP-routed logic functions in a workspace compete for any public domain — first match wins nondeterministically. ## Backend - Added nullable `applicationId` FK to `PublicDomainEntity` (cascade-deleted with the app); indexed for the route-trigger lookup. - New fast instance command `2-4-instance-command-fast-1798000003000-add-application-id-to-public-domain` adds the column, index, and FK constraint. - `createPublicDomain(domain, applicationId)` accepts an optional app binding; new `updatePublicDomain(domain, applicationId)` mutation rebinds/unbinds an existing domain. Both validate the application belongs to the workspace. - `WorkspaceDomainsService.resolveWorkspaceAndPublicDomain(origin)` returns both the workspace and the matched public domain in one query — replacing the old back-to-back lookups in the route-trigger hot path. `getWorkspaceByOriginOrDefaultWorkspace` is preserved as a thin wrapper. - `RouteTriggerService` filters `logicFunction` by `applicationId` when the matched public domain is app-scoped; falls back to workspace-wide when unbound. - Three sequential validation queries in `createPublicDomain` now run in parallel via `Promise.all`. ## Frontend | Old location | New location | |---|---| | Settings sidebar → Domains (standalone page) | Removed | | Domains page → Workspace Domain | General page | | Domains page → Approved Domains | Members → Access tab | | Domains page → Emailing Domains | Apps → Developer tab | | Domains page → Public Domains | Apps → Developer tab | | Settings sidebar → Roles (standalone) | Members → Roles tab | | `pages/settings/roles/` | `pages/settings/members/roles/` | - The Public Domain detail page has an Application picker that uses `Select`'s native `emptyOption` + `null` value pattern (matches `SettingsDataModelObjectIdentifiersForm`). - Members page tabs use the existing `TabListFromUrlOptionalEffect` mechanism (rendered automatically by `TabList`) for hash-based tab activation. - `/settings/members/roles` redirects to `/settings/members#roles` so role sub-pages' `navigate(SettingsPath.Roles)` lands on the Members page with the Roles tab pre-selected. - All affected breadcrumbs updated to nest under their new parents. - `SettingsPath.Roles` and friends now nest under `members/`; `Subdomain` and `CustomDomain` under `general/`; `PublicDomain` and `EmailingDomain` under `applications/`. ## Test plan - [x] `nx typecheck twenty-front` passes - [x] `nx typecheck twenty-server` passes - [x] `oxlint --type-aware` clean on all touched files - [x] `prettier --check` clean on all touched files - [x] Migration applied locally; `publicDomain.applicationId` (uuid, nullable) confirmed in DB - [x] GraphQL schema exposes `PublicDomain.applicationId`, `createPublicDomain.applicationId`, `updatePublicDomain` mutation - [x] **End-to-end route resolution scenarios verified locally:** - Domain bound to App A, function in App A → route matches ✅ - Domain bound to App B, function in App A → route does NOT match (HTTP 404 `TRIGGER_NOT_FOUND`) ✅ - Domain unbound (`applicationId = NULL`) → route matches workspace-wide ✅ - Unknown path on bound domain → returns 404 cleanly ✅ - [x] UI sanity (browser-tested at `apple.localhost:3001`): - General page shows Workspace Domain card - Members page shows Team / Access / Roles tabs - Access tab combines Invite by link + by email + Approved Domains - Roles tab embeds the role list - `/settings/members/roles` direct URL → redirects + Roles tab pre-selected - Apps Developer tab shows Emailing Domains + Public Domains sections - Public Domain detail page has Application picker dropdown listing workspace apps - Sidebar nav: "Domains" and "Roles" no longer present (now folded into General/Members) ## Notes for reviewers - Creating a public domain via the UI still requires Cloudflare credentials in the dev `.env` (`CLOUDFLARE_API_KEY`, `CLOUDFLARE_PUBLIC_DOMAIN_ZONE_ID`, `PUBLIC_DOMAIN_URL`). The DNS step is unchanged from main. - The `applicationId` column is nullable, so existing public-domain rows continue to work workspace-wide — no data backfill required. - `SettingsRolesContainer` was deleted (no longer referenced after `SettingsRoles` index page was removed). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
59 lines
2.0 KiB
Plaintext
59 lines
2.0 KiB
Plaintext
---
|
|
title: AI
|
|
description: AI-powered features coming soon to Twenty.
|
|
---
|
|
|
|
<Frame>
|
|
<img src="/images/user-guide/workflows/robot.png" alt="AI" />
|
|
</Frame>
|
|
|
|
## What's Coming
|
|
|
|
Twenty is building AI capabilities to help your team work smarter. We're focusing on two major areas:
|
|
|
|
### 1. AI Chatbot
|
|
|
|
A conversational assistant that understands your context and has access to all your Twenty data.
|
|
|
|
**Key capabilities:**
|
|
- **Full data access**: Query any record, relationship, or metric in your workspace
|
|
- **Page context awareness**: Reference "this company" or "this opportunity" based on where you are in Twenty
|
|
- **Natural language**: Ask questions and get answers without navigating menus
|
|
|
|
**Example prompts:**
|
|
- "What opportunities are closing this month?"
|
|
- "Which deals have been in Negotiation for more than 30 days?"
|
|
- "Summarize my interactions with this person"
|
|
|
|
### 2. AI Agents in Workflows
|
|
|
|
Extend your workflows with AI-powered actions and autonomous agents.
|
|
|
|
**Key capabilities:**
|
|
- **AI actions**: Use AI to enrich data, classify records, generate summaries, and more
|
|
- **Autonomous agents**: Let agents execute multi-step tasks within a workflow
|
|
- **Custom prompts**: Define exactly how AI should process your data
|
|
|
|
**Use cases:**
|
|
- Automatically categorize inbound leads
|
|
- Enrich company data from public sources
|
|
- Generate follow-up email drafts based on meeting notes
|
|
- Score opportunities based on engagement patterns
|
|
|
|
## Permissions and Access Control
|
|
|
|
AI agents will be managed through the existing permissions system:
|
|
|
|
1. Go to **Settings → Members → Roles**
|
|
2. Configure which data each AI agent can access
|
|
3. Set read/write permissions per object
|
|
|
|
This ensures AI agents respect your data governance policies and only access what they need.
|
|
|
|
## Stay Updated
|
|
|
|
We'll update this section as AI features become available. In the meantime:
|
|
|
|
- Follow our [GitHub](https://github.com/twentyhq/twenty) for development updates
|
|
- Join our [Discord](https://discord.gg/UfGNZJfAG6) to share feedback and feature requests
|