{"title":"Atlas changelog","homePageUrl":"https://atlas.wrxstack.com/changelog","feedUrl":"https://atlas.wrxstack.com/v1/changelog/feed.json","items":[{"id":"1.196.0","url":"https://atlas.wrxstack.com/changelog/release-1-196-0","title":"Custom domain guides, full-screen pages and names everywhere","summary":"Step by step guides for putting the client portal on your own domain at twenty DNS providers, pages that use the whole screen, one consistent way things move, and people and engagements shown by name across Atlas.","content_text":"# 1.196.0: Custom domain guides, full-screen pages and names everywhere\n\n## New\n\n- **Custom domain guides.** A guide to putting the client portal on a web address your firm owns, from choosing the address to the moment it goes live, with a page for each of twenty DNS providers, including Hostinger, GoDaddy, Namecheap, Squarespace and Amazon Route 53. Each page names the provider's own menus and fields, shows the exact values to enter, links to the provider's help, and says plainly where a detail could not be confirmed. Settings, Client Delivery links to it beside the records to add.\n- **One way things move.** Dialogs, menus, drawers, toasts and page changes now move at the same few speeds, close as smoothly as they open, and respect a request for reduced motion. Drawers open from the correct side in Arabic and Hebrew.\n\n## Improved\n\n- **Pages use the whole screen.** Settings, Client Delivery, the client portal guide, Super Admin, People and the documentation lay out in columns on a wide screen instead of a narrow strip.\n- **Names, not codes.** HR administration pages, HR reports, contract analytics, privacy consents, GitHub installations and Granola folder routing show people and engagements by name. Granola folders are now routed to an engagement chosen from a list.\n- **Your own record, found for you.** Requesting leave and recording attendance use your own employee record without asking you to pick it, and probation and role changes offer people, departments and locations by name.\n\n## Fixed\n\n- **Names in every module.** Names of colleagues on tasks, deals, engagements and other records no longer depend on the Incident Management module being part of your plan.\n- **Attendance for the right person.** Clocking in or out for someone else is limited to your direct reports, or to anyone for an administrator, the same rule as requesting leave.\n- **A meeting that cannot be found** now says so in plain words, with a way back to your meetings.\n- **Opening an invitation while signed in as someone else.** Sign in with that address now signs you out and brings you back to the invitation after you sign in, instead of losing it.\n- **Opening the same invitation twice.** Reloading or reopening an invitation you have already accepted opens your portal instead of showing an error.\n- **The portal link on an engagement** goes to your firm's own portal address when it has one.\n- **Clients no longer receive the firm's morning briefing.** A client portal seat does not make someone a member of the firm's workspace.","date_published":"2026-10-12T09:30:00.000Z","tags":["feature"]},{"id":"1.195.0","url":"https://atlas.wrxstack.com/changelog/release-1-195-0","title":"A new client portal, and new ways to sign in","summary":"The client portal is rebuilt around a sidebar, dashboards and analytics, with a register for every section, a notification bell, new threads and review history, and the sign-in pages are redesigned with passkeys, sign-in links and single sign-on.","content_text":"# 1.195.0: A new client portal, and new ways to sign in\n\n## New in the client portal\n\n- **A sidebar for every engagement.** The portal now has a navigation bar on the left, grouped into Home, Work, Conversations, Governance, Files and People, with a count beside each item that is waiting on the client. It folds to icons on a wide screen and opens from a menu button on a phone. The firm's name, logo and colour head it, and the client's own name and picture sit at its foot with the account menu.\n- **A portfolio home.** A client sees every engagement they can open on one page: what is waiting on them, the health and progress of each engagement, its next milestone, and everything due in the next 14 days. A client with one engagement goes straight to its dashboard, and the home is always one click away.\n- **An engagement dashboard.** Progress, overall health and its history, the next milestone with the days remaining, deliverables by stage, requests by age, actions due, changes awaiting a decision with their cost and schedule effect, the latest status report, upcoming meetings and recent activity.\n- **Analytics.** A page of charts over the last 30, 90 or 365 days or the whole engagement: deliverables accepted and time in client review, requests raised against answered and their turnaround, milestones planned against actual, the cumulative effect of changes, health across periods, how quickly the firm answers threads, and the commercial position when the firm shares it.\n- **A register for every section.** Each section opens with its key figures and a chart, then a list the client can search, filter and sort, which the browser remembers. A row opens its details in a side panel or on its own page. Risks and decisions lists the risks, issues and decisions the firm chose to show the client.\n- **New thread.** A client who can act can start a conversation with the engagement team from the Threads page or from the dashboard, with a title, a message and its kind. The engagement team is told at once.\n- **Notifications in the portal.** A bell in the top bar shows what changed on the engagement since the client last looked, with an unread count. Items are marked read after the client has looked for a moment, or at once with Mark all as read, and the bell checks for news every minute while the tab is in view.\n- **Review history on a deliverable.** Each version issued to the client with its files, each client review round with its outcome and dates, and the sign-offs from the client's organisation with their comments, beside the sign-off itself.\n- **Documents.** Preview a PDF or an image in place, filter by who shared it, by type (including spreadsheet, document and presentation) and by month, and search by name.\n- **Uploads.** Send several files at once, by dragging them in or choosing them, against a request or into the document library, with progress shown for each file.\n- **Add to calendar.** Upcoming meetings download as a calendar file.\n- **Print or save as PDF.** The dashboard and the analytics page print cleanly, and the print dialog saves them as a PDF.\n\n## Improved in the client portal\n\n- **Light and dark.** Every portal page follows the light, dark or device theme chosen in the account menu, and the charts recolour with it.\n- **Your language, everywhere.** A language chosen in the account menu is saved to the client's profile as well as the browser, so it follows them to another device. Every portal page reads in each of the ten supported languages, and right-to-left languages mirror the layout.\n- **Your colour.** The firm's colour becomes the portal's accent wherever it is readable against the page, and the Atlas colour stands in where it is not.\n\n## New ways to sign in\n\n- **Redesigned sign-in pages.** Sign in, create an account, choose a workspace, reset a password and accept an invitation now share one layout, with the ways in listed in order and no marketing footer. On a firm's own portal address the pages carry the firm's name, logo and colour.\n- **Passkeys.** Add, rename and remove passkeys in security settings, and sign in with one instead of a password. A passkey counts as two-step verification.\n- **Sign-in links.** Ask for a link by email instead of typing a password. A link works once, for 15 minutes.\n- **Single sign-on.** Use single sign-on finds your workspace from your work email address and starts its sign-in, or says when single sign-on is not set up for that address. It works for a company domain an administrator has verified: owners and administrators add their domains in security settings and prove each one with a DNS record.\n- **Easier to get right.** The password strength meter shows the rules as you type, the eye button shows the password, a warning appears when Caps Lock is on, and the page remembers how you last signed in.\n- **Choose a workspace.** Each workspace is a card with its plan, your role, its members and projects, the one you used last at the top, a search when there are more than five, and client portals listed on their own.","date_published":"2026-10-11T13:00:00.000Z","tags":["feature"]},{"id":"1.194.1","url":"https://atlas.wrxstack.com/changelog/release-1-194-1","title":"Names on a new engagement team, and a quicker sign-in code","summary":"The partner and manager chosen for a new engagement are shown by name to the firm and to the client, the sign-in code field opens a number pad and offers the emailed code, and the domain queue says when nothing has been requested.","content_text":"# 1.194.1: Names on a new engagement team, and a quicker sign-in code\n\n## Fixed\n\n- **Unnamed team members.** The partner and manager chosen when an engagement was created joined its team without a name, so the People screen listed them as Unnamed and the client portal as Team member. They now carry their names, and engagements created before this release are corrected.\n- **The sign-in code field** on the sign-in and sign-up pages now opens a number pad on a phone and offers the code from the email, as the authenticator code field already did.\n- **The domain approval queue** for Super Admins said no domains matched its filters when no firm had asked for one. It now says that no firm has asked yet, and mentions filters only when they hide something.","date_published":"2026-10-11T06:30:00.000Z","tags":["fix"]},{"id":"1.194.0","url":"https://atlas.wrxstack.com/changelog/release-1-194-0","title":"The client portal at your own address, and in your language","summary":"Firms can give the client portal a web address of their own, clients without an account get in with an emailed code, and the portal and sign-in pages read in every supported language.","content_text":"# 1.194.0: The client portal at your own address, and in your language\n\n## New\n\n- **A web address for your portal.** Owners and administrators can choose a name for the portal under the portal domain, or connect a domain the firm owns, such as portal.yourfirm.com, in Settings, Client Delivery. Atlas shows the DNS records to publish, checks for them, and tells you when the address is live. Invitations and emails then link there. Settings shows when this is available for your workspace.\n- **Clients without an account.** A client invited to the portal who has no Atlas account now gets a sign-in code by email at the invited address, and their account is made when they enter it. Sign-up for an invited client asks only for a name and an email address.\n- **Add the client to invite.** The invitation panel now adds the client contact in place, with the address the invitation goes to, and lists the contacts of the engagement client first.\n- **Domain notices.** Owners and administrators are told in Atlas when a domain the firm added goes live, is not approved, or could not be set up.\n- **Public API.** The public routes, such as signing links, calendar feeds, the status page and SCIM, are now described in the API reference, with the credential each one needs.\n\n## Fixed\n\n- **Emails from Atlas.** Invitations, reminders and client notices were recorded as sent while no email left. They are now delivered, from the address your sign-in emails already use.\n- **The sign-in code email** said a code lasted five minutes in one line and ten in another. It now states the real lifetime.\n- **The partner and manager named on a new engagement** are now on its team, so a playbook fills their seats instead of reporting them empty.\n- **Words instead of codes.** Engagement status, health, review tiers, meeting kinds and access in the client portal and on engagement screens now read as words in the reader's language, instead of stored values or English.\n- **The client portal.** All section tabs are visible on a wide screen, a client who can only read is offered only the notices they can receive, and the overview no longer says nobody is on the team when it has not checked.\n- **Sign-in pages** are now translated in every supported language, and French, Spanish and Portuguese text has its accents and apostrophes restored throughout.","date_published":"2026-10-11T05:10:00.000Z","tags":["feature"]},{"id":"1.193.17","url":"https://atlas.wrxstack.com/changelog/release-1-193-17","title":"A client portal you can set up and rely on","summary":"Firms set up their client portal in Settings, share threads, deliverables and meetings with clients, and clients are emailed when something needs them. Emails Atlas queued are now delivered.","content_text":"# 1.193.17: A client portal you can set up and rely on\n\n## New\n\n- **Portal settings.** Owners and administrators set how the client portal runs in Settings, Client Delivery: whether it is on, whether clients see a budget summary, how many days a finished engagement stays open to its client, how long an invitation can be accepted, and the access level a new invitation starts at.\n- **Share more with your client.** Threads, deliverables and meeting forums can now be shared with the client from the record itself, under Who can see this, and withdrawn with a reason. The thread and deliverable lists mark what the client can see.\n- **A conversation in every thread.** The thread screen shows the client's replies and your team's, each marked as visible to the client or internal, and your team answers there, for the client or as an internal note. The owner of the thread is told when a client replies.\n- **Emails for your clients.** A client is emailed when a status report reaches their portal, when a deliverable, minutes or a change request waits for their approval, when your firm replies in a thread they can read, and when something they owe is overdue, once and then weekly. Each email is signed with your firm's name, and each client chooses which they receive on the Notifications page of their portal.\n- **Invitations by workstream.** An invitation can be limited to particular workstreams, and each invitation not yet accepted has its own Revoke control.\n- **Client portal guide.** A new guide in the documentation explains setting up the portal, inviting clients, deciding what they see, email notifications, where clients sign in and what to do when something goes wrong. The guide inside Client Delivery is brought up to date.\n\n## Fixed\n\n- **Emails that were never sent.** Portal invitations, follow-up chasers, customer updates and contract reminders were placed in a queue that nothing delivered, while the screen reported them sent. They are now delivered within a minute of being queued. Emails queued before 10 October 2026 are marked as not sent rather than delivered weeks late.\n- **An invitation reported as sent when mail was not set up.** Where this workspace cannot send email, the invitation now says so and shows the link to pass on.\n- **A logo that disappeared.** A logo uploaded in Settings, Branding was lost when the page reloaded and never reached the client portal. It is now stored and appears for every client.\n- **Links into the portal.** A link to an engagement, in an email or a bookmark, said the engagement was not available to a client who works with more than one firm or who signed in to their own space. It now opens the engagement.\n- **Read-only access.** A client with restricted guest access was offered approve, reply and upload buttons that always failed. Those buttons are now hidden, with a note on how to ask for more access, and the access levels say what a client can do rather than describing narrower and fuller views.\n- **Uploads belong to their sender.** One client could complete a file upload started by another client on the same engagement. Each upload now belongs to the person who started it.\n- **Documentation titles.** Nine documentation pages named the documentation twice in the browser tab.","date_published":"2026-10-10T22:00:00.000Z","tags":["breaking"]},{"id":"1.193.16","url":"https://atlas.wrxstack.com/changelog/release-1-193-16","title":"Clients stay in their portal","summary":"An invited client can no longer open the firm's workspace, finds their portal from the account menu, and the sidebar names Workspaces as the page it opens.","content_text":"# 1.193.16: Clients stay in their portal\n\n## Fixed\n\n- **A client could open the firm's workspace.** Accepting a client portal invitation gave the client a guest seat in the firm's workspace, and that seat also let them switch into the workspace and read it as a guest. A portal seat is now only that: the firm's workspace is not in the client's list, switching into it is refused, and every request outside the portal and the client's own profile is refused. Clients who already held a seat are covered too. A guest the firm invited to its workspace on purpose is not affected.\n- **A removed member and a client link.** A person the firm had removed from its workspace got the workspace back by accepting a client portal invitation. They now get the portal and nothing more.\n- **Inviting a client into the team.** Team settings refused to invite somebody who held a client portal seat, saying they were already a member. They can now be invited, and accepting makes them a member with the role chosen.\n\n## Improved\n\n- **Finding the portal.** A client who signs in on the usual sign-in page now finds Client portals in the account menu. It appears only for people who hold portal access. A person whose only access is a client portal is given a personal space of their own when they sign in, and reaches the portal from the same menu.\n- **Workspaces in the sidebar.** The sidebar link to the workspace settings said Spaces; it now says Workspaces, like the page it opens, in every language.","date_published":"2026-10-10T18:30:00.000Z","tags":["breaking"]},{"id":"1.193.15","url":"https://atlas.wrxstack.com/changelog/release-1-193-15","title":"Know when a customer update arrived","summary":"Every sent customer update now shows where each email got to, an interrupted send can be finished, and a meeting series preview says what it can show.","content_text":"# 1.193.15: Know when a customer update arrived\n\n## Improved\n\n- **Where each email got to.** Under every sent customer update, each customer is listed by name with what happened to their email: waiting to send, sending, sent and awaiting confirmation, delivered, bounced, marked as spam, or not delivered. It checks again every thirty seconds while an email is still on its way. Until now the update said only that the emails were queued.\n\n## Fixed\n\n- **An interrupted send.** If the server stopped part way through sending a customer update, the update stayed in sending for good and could not be sent again. Sending again after ten minutes now finishes it, and no customer is emailed twice.\n- **Meeting series preview.** Asking a meeting series to preview more than a year of weekly sittings quietly returned fifty two. It now says that fifty two is the most it shows.\n- **Signing before answering the cookie notice.** On the public signing page, the cookie notice covered the Sign agreement button on a laptop screen, so a signer had to answer the notice before they could sign. Every page outside the app now leaves room below its last button, so it can be scrolled clear of the notice.\n- **Menus on a phone.** Choosing Latest updates, Keyboard shortcuts or Send feedback from the account menu in the phone navigation drawer opened the panel with the drawer still open beneath it. The drawer now closes first.\n- **A reply Atlas could not read.** When a screen received a web page instead of data, for example during an update, it showed the browser's own error text. It now says that Atlas is briefly unavailable and offers Retry.\n- **Importing a JSON file.** A file that is not valid JSON, imported from Settings, Data, now says so in words rather than quoting the browser.","date_published":"2026-10-10T18:00:00.000Z","tags":["fix"]},{"id":"1.193.14","url":"https://atlas.wrxstack.com/changelog/release-1-193-14","title":"Due today means today, wherever you are","summary":"Each workspace says whether it is personal or team, creating one works from everywhere, days follow your own time zone, customer updates are emailed, and information barriers hide the engagement they protect.","content_text":"# 1.193.14: Due today means today, wherever you are\n\n## Fixed\n\n- **Due today on Home.** East of Greenwich, Home listed tasks due yesterday as due today and left out the ones actually due today, all day long. It now uses your own day.\n- **Overdue counts.** Reports and Analytics counted a task as overdue from the start of the day it was due. A task is now overdue only once its due day has passed.\n- **Days in reports and planners.** Completed work, tracked time, the first block of focus time, the workload window on My Work, status report periods, the People reports date range and the Auto-schedule planner now follow your own day and clock. Auto-schedule also labels each day with its own date in every time zone.\n- **Missing or unavailable.** About sixteen screens, among them incidents, postmortems, meetings, client portal pages and shared links, said a record may have been deleted when Atlas was only briefly unavailable. They now say it could not be loaded and offer Retry, and say it is missing only when it is.\n- **Partial answers.** The offer page, the CRM activity feed and deals, the briefing and Home project widgets say when part of what they show could not be loaded, rather than presenting it as complete.\n- **Creating a project.** If the project tags and custom fields could not be read, a project could be created without its required fields. Creating now waits until they load.\n- **Sharing a task.** A shared task summary could include internal label codes. It now leaves out a label it cannot name and writes field names in words.\n- **Exit interview.** If Atlas could not check whether your answers were already on file, it now says so before you start, with Retry.\n- **Loading figures.** Payroll tiles and onboarding counts no longer show zero while they are still loading.\n- **Settings.** Client onboarding, data export history, follow-up rules, connected assistant apps and calendar systems each offer Retry when they cannot load, and calendar systems no longer present a default as your saved setting.\n- **Incident soak window.** If your workspace window could not be read, the wait now says the default is in use.\n- **Knowledge graph and analytics.** A failed read no longer shows an empty graph or an empty conversion funnel.\n- **People pickers.** When the workspace member list could not be read, every screen with an assignee picker stopped working. The picker now says the list could not load and offers Retry, and the rest of the screen keeps working.\n- **Recent files and meeting providers.** PDF conversion history, capture history and the meeting provider status now say when they could not be read, instead of showing nothing.\n- **Declaring an incident.** A double tap, or a retry on a poor connection, now declares one incident rather than two.\n- **Compliance dashboard.** The dashboard showed the same fixed list of SOC 2 and ISO 27001 controls, most marked compliant, to every workspace, and scored it. It now lists your own controls and marks one compliant only when its latest evidence passed and has not expired. A workspace with no controls is told so, and two evidence links that led nowhere are gone.\n- **Connectors.** The Connectors page showed eight of the twenty-seven connectors Atlas offers, called Google Drive and HubSpot coming soon although both work, and showed every connector as not connected. It now lists every connector, says which ones your workspace has connected, and says so when that could not be read.\n- **Board lanes.** A task whose status had no column of its own was filed under To do, where moving it changed its status, and with no columns at all it disappeared. Each such status now has its own lane.\n- **Server settings shown to customers.** Meeting settings, the meeting transcript, the push notification switch and diagram code rendering told you to set server keys or ask an administrator to configure services, which nobody in a workspace can do. They now say plainly what is available and what to use instead, and the server settings are shown to the Super Admin who runs the deployment.\n- **Language and Data residency.** Language said nine languages were active when there are ten; it now counts them. Data residency now says plainly that stored data is not moved when the region choice changes.\n- **Workspace switcher.** The switcher at the top of the sidebar could not read your workspaces at all, and showed an invented Default workspace in their place. It now lists every workspace you belong to.\n\n## Improved\n\n- **Each workspace says what it is.** The workspace picker, the switcher at the top of the sidebar and Settings now show beside each name whether it is a team workspace or a personal space, and which plan it is on. Those two decide which apps a workspace has.\n- **One way to create a workspace.** Creating a workspace from the sidebar switcher made a hidden record inside the current workspace that never appeared anywhere, and the link on the workspace picker led back to the picker. Every create link now opens one form that asks whether the workspace is for a team or for home, starts on a team workspace, creates it, and opens it.\n- **Team apps no longer vanish.** In a personal space, People and Client Delivery used to disappear without a word. The sidebar now shows More apps, and the Apps page marks them as available in team workspaces with a link to create one. An owner or administrator looking at an app the plan does not include is offered the plans, rather than told to ask an administrator.\n- **Clearer names.** The directory of apps is now called Apps, and Settings, Spaces is now Settings, Workspaces, so the word workspace means one thing everywhere.\n- **Customer updates are sent.** Sending a customer update on an incident now emails the primary contact of each affected customer, and the screen lists who was emailed and who could not be reached, and why. Only customers who were actually emailed are marked as told.\n\n## Security\n\n- **Information barriers hide the engagement.** A barrier raised without choosing where it applies now hides the engagement itself, and every record in it, from the people it walls off, as well as its portal and search entries. Barriers raised before this release protect their engagement at the points they recorded; until now they protected nothing. The people a barrier excludes can no longer read or change that barrier.\n- **Wall crossings.** A crossing must be approved by a current owner or administrator of the workspace other than the person crossing, and nobody can record their own crossing.\n- **Client Delivery records.** Every Client Delivery screen and API now checks that you may see the engagement before reading or changing anything in it, and refuses a record from another engagement named in a request, such as a rate card, a deliverable or an attachment.\n- **Client portal.** The portal now accepts only a signed-in client. Personal access tokens and OAuth tokens are refused on every portal address, and an observer seat can no longer approve or sign off.","date_published":"2026-10-10T12:00:00.000Z","tags":["fix"]},{"id":"1.193.13","url":"https://atlas.wrxstack.com/changelog/release-1-193-13","title":"Your own day everywhere, and no more false \"nothing here\"","summary":"Dates, streaks, heatmaps and attendance now follow your own day rather than UTC, and screens that could not load say so instead of showing an empty list or a calm summary.","content_text":"# 1.193.13: Your own day everywhere, and no more false \"nothing here\"\n\n## Fixed\n\n- **Your own day.** Between midnight and the moment your time zone caught up with UTC, many screens still used the previous day: the quick due date picker, overdue counts, the workload week, activity heatmaps, habit and journal streaks, the activity feed headings, and dates filled in for you on forms and file names. They now all follow your own clock.\n- **Attendance.** Daily attendance and the attendance log counted the day in UTC, so an early morning check in could land on the previous day. They now count the day in your time zone.\n- **AI capture, Ask and stand-ups.** The AI assistant now reads \"today\" from your profile time zone, or your browser when none is set, so a task captured just after midnight is not filed as overdue.\n- **Screens that could not load.** When a section could not load, about two hundred screens showed their empty state instead, such as \"No items yet\", zero totals, \"You are all caught up\" or \"All quiet\". They now say the section could not load and offer Retry. Editors that could have saved an empty form over your real data stay locked until they load.\n- **Status page.** If incident history or performance data could not be read, the status page said \"All quiet\" or drew empty charts. It now says it could not load them and offers Retry.\n- **Today widget.** The home screen widget said \"You are clear for today\" while it was still syncing, offline or failing to sync. It now says which of those it is.\n- **Activity feed.** The activity feed and its Home widget now load from the right place, and say so when they cannot.\n- **Workspace members and activity timeline.** Two panels that could not load at all now show your members and recent activity.\n- **Home widgets across projects.** Widgets that read every project, such as the risk register and milestone lists, said \"No open risks: looking clear\" when some projects could not be read. They now say they may be incomplete and offer Retry.\n- **Unsaved work after a failed read.** Editors that could have saved an empty form over your real data, among them branding, notification preferences, diagram rules, the journal and the tax profile, now stay locked until your data has loaded.\n- **Data residency.** When pinning a region was refused, the page said it could not load and your choice was lost. It now keeps your choice and says why the pin was refused.\n- **On-call setup.** When escalation policies could not be read, the setup panel offered to create a policy as if you had none. It now says the policies could not be read and offers Retry.\n- **Projects.** \"Active this week\" no longer shows zero while your tasks are still loading.\n- **Briefing.** If your calendar, tasks or habits could not be read, the briefing now says that part could not be read instead of telling you your day is clear, and still reads you the rest.\n- **CRM breadcrumbs.** Account, contact and pipeline pages showed a record code in the breadcrumb, and accounts showed two breadcrumb trails. The breadcrumb now names the record, once.\n- **Workload.** A day booked beyond capacity showed 100% while its warning said 125%. Each day now shows its true share, and work booked on a day off shows how many hours rather than \"off\".\n- **Legal holds.** The hold date on a data subject request is now chosen with the same date picker as the rest of Atlas.","date_published":"2026-10-10T00:00:00.000Z","tags":["fix"]},{"id":"1.193.12","url":"https://atlas.wrxstack.com/changelog/release-1-193-12","title":"Agents load again, and two wizards stop at their review step","summary":"The Agents page loads its templates, runs and approvals again, the profile card on Home shows your real progress, and the new engagement and new agreement wizards no longer act before you have reviewed what they will do.","content_text":"# 1.193.12: Agents load again, and two wizards stop at their review step\n\n## Fixed\n\n- **New agreement.** Pressing Next on the signers step could send the agreement for signature straight away, without showing the review step. Next now always stops at the review, and nothing is sent until you press \"Send for signature\".\n- **New engagement.** Pressing Next on the step before review could create the engagement without showing the review. Next now always stops at the review, and nothing is created until you press Create.\n- **Dates you type.** After midnight, and before your time zone caught up with UTC, typing \"today\" or \"tomorrow\" in a new task set the day before, so the task arrived overdue. In India that was every night from midnight to 5:30. Dates you type now follow your own clock, on the web and in the mobile app.\n- **Agents.** The Templates, Runs and Approvals tabs said they could not load. They load again.\n- **Profile card on Home.** The profile completeness card showed every profile as empty. It now shows the same percentage and the same fields as your profile page.\n- **Sales playbooks.** Switching to another step in the playbook editor discarded an unsaved change to the playbook's priority or its on and off switch. Those changes are now kept.\n- **Loading on a busy device.** On a slow or busy device a page could redraw itself while loading and record an error. It now loads once.\n- **Dark themes.** Buttons and filters, among them the agent template filters, Run and Approve on Agents, and the confirm buttons on data export and account deletion, showed white text on a light colour in dark themes and were hard to read. They now use the text colour the theme pairs with each fill.\n- **Client portal.** The firm's colour and name could disappear for a moment while the portal loaded. They now stay in place.\n- **Workflow scripting.** Where JavaScript scripts are turned off, the page opened on JavaScript and the first run failed with a technical message. It now opens on Python and says plainly that JavaScript is off.\n- **Clause library.** A workspace with no clauses saw an empty grid on the Contracts Clauses tab. It now says there are no clauses yet and links to the full library.","date_published":"2026-10-09T00:00:00.000Z","tags":["fix"]},{"id":"1.193.11","url":"https://atlas.wrxstack.com/changelog/release-1-193-11","title":"Every dropdown in your theme, and plain words in place of codes","summary":"Dropdowns across Atlas now open a list in your theme instead of the system menu, and lists that showed stored codes such as IN_PROGRESS now say what they mean.","content_text":"# 1.193.11: Every dropdown in your theme, and plain words in place of codes\n\n## Improved\n\n- **Dropdowns.** About 260 dropdowns across Atlas used the system menu, which ignores your theme and shows a white list on a dark screen. They now open a themed list that wraps long labels, sizes itself to fit, and stays inside the window.\n- **Plain words.** Lists that showed stored codes now show words: task statuses and priorities, workspace roles, field policies, form field kinds, formula return types such as \"Yes or no\" and \"Text\", engagement status colours, calendar providers and project statuses.\n- **AI providers.** Every settings screen now names your AI provider the same way.\n- **Agent templates.** Templates show an icon rather than an emoji, \"Calendar tetris\" is now \"Day planner\", and \"Q-end report\" is now \"Quarter-end report\". A count of one reads \"1 run\".\n- **Meetings.** Action items read \"Owner\" and \"Due\" rather than emoji.\n\n## Fixed\n\n- **Source grading.** Choosing \"Not assessed\" for a source's credibility was refused. It now clears the grade.\n- **Seats and voters.** A meeting seat for someone with no name on record named their internal key. It now names their email or seat.\n- **Audit log.** The guide now says, correctly, that audit events are kept until an owner or admin sets a retention window.\n- **HR policies.** \"Slug\" is now \"Short name\", with a note on what it is for.","date_published":"2026-10-09T00:00:00.000Z","tags":["fix"]},{"id":"1.193.10","url":"https://atlas.wrxstack.com/changelog/release-1-193-10","title":"Plans that match pricing, honest security pages, and working API clients","summary":"Every plan now includes exactly what the pricing page lists, the public pages describe only security controls Atlas has, and the Python, Go and Ruby API clients download from Atlas and call the right address.","content_text":"# 1.193.10: Plans that match pricing, honest security pages, and working API clients\n\n## Fixed\n\n- **Plans.** Pro, Team and Business now include every module, feature and limit the pricing page lists. A Team workspace, for example, now has CRM, contracts and analytics, and up to 25 editors. Monthly intelligence credits now match the pricing page too: 200 on Free, 10,000 on Team and 50,000 on Business, which is fewer than those plans allowed before.\n- **API clients for Python, Go and Ruby.** The documentation told developers to install packages that Atlas does not publish, and the clients called an address that is not Atlas. Each client is now a single file you download from Atlas, with a checksum, and it calls the Atlas API. Calls that take an id, such as getting one task, now work.\n- **Wording.** Sentences across Atlas, its emails and its PDFs no longer use a spaced hyphen as a dash, and ranges of dates and times read with \"to\".\n- **Task details.** A subtask with an unreadable due date no longer prints the raw value.\n- **Names, not codes.** The reimbursement queue names each employee instead of showing an internal id, a candidate whose role was removed reads \"Opening unavailable\", and a settlement status reads \"Calculated\" rather than \"CALCULATED\".\n- **Dates.** A one-day leave request shows its date once, a project with one date reads \"Starts\" or \"Ends\", a project with no readable dates shows none, and Reports says \"1 day\" rather than \"1 days\".\n- **Emails.** A booking guest without a name is greeted \"Hi there\" rather than \"Hi ,\".\n- **Pickers.** Empty choices in People read \"Select an employee\" rather than \"- Employee -\".\n- **Audit log guide.** The guide said events are kept for 90 days. They are kept for seven years by default, and owners and admins can change that.\n\n## Improved\n\n- **Trust Center and public pages.** They now list the security controls Atlas has, such as SSO, SCIM, two-factor sign-in and a tamper-evident audit log, and say plainly that Atlas does not yet hold a SOC 2 or ISO 27001 certification. Evidence packs help you prepare for your own audits.\n- **Atlas Intelligence.** Pricing and the Intelligence pages called it on-device AI. It runs its own models on Atlas servers and never sends your content to an outside AI provider, and the pages now say exactly that. The cookie notice no longer calls Atlas GDPR or CCPA ready, and its choices fit a phone screen.\n- **Home page.** Plans and figures come from the same source as the pricing page, and the customer examples describe how teams can use Atlas.\n- **Greeting.** The greeting on Home and My Work is a plain salutation, without emoji.\n- **Meeting templates.** Templates show an icon and their length in minutes, and Retro is now Retrospective.\n- **Dropdowns.** More dropdowns open a list in your theme rather than the system menu.\n- **Search.** The search hints suggest filters you can type, such as priority:high.","date_published":"2026-10-09T00:00:00.000Z","tags":["fix"]},{"id":"1.193.9","url":"https://atlas.wrxstack.com/changelog/release-1-193-9","title":"Phone layouts, readable dates and plain words across Atlas","summary":"Incident and client onboarding pages fit a phone, timelines no longer print dates on top of each other, dates read as dates, and labels across Atlas say what they mean.","content_text":"# 1.193.9: Phone layouts, readable dates and plain words across Atlas\n\n## Fixed\n\n- **Phone layouts.** On a phone, the incident and client onboarding pages squeezed their title down to a few letters behind the buttons. The title now keeps its space and the main action sits on its own row. Tabs such as those on Incident reviews no longer print over each other.\n- **Timelines.** On a narrow screen, the dates along the client onboarding, on-call and customer update timelines ran into each other. Each timeline now shows as many dates as fit.\n- **Dates.** Workload and Attendance showed their week as \"2026-10-05 to 2026-10-11\". They now read \"Oct 5 to Oct 11, 2026\", in your own date format.\n- **Page titles.** Browser tabs and search results named Atlas twice, as in \"Security · Atlas · Atlas\". Every page now names it once, and a changelog entry is titled by its release number.\n- **Error messages.** The sales forecast, the CRM and the payments screen for administrators showed an internal address or a code such as \"Request failed with 500\" when something failed. They now say what happened in words.\n- **Task details.** Status, priority and visibility read \"To do\", \"In progress\" and \"Urgent\" rather than \"todo\" or \"urgent\", and the subtask suggestion says which status to choose.\n- **Incident reviews.** A single unfiled follow-up read \"1 are not filed\". It now reads \"One is not filed as a task yet\".\n- **Settings.** \"Workspace export\" and other administrator pages were cut short beside an \"Admin only\" badge. The badge now reads \"Admin\", with the full meaning on hover.\n\n## Improved\n\n- **Meetings.** The recording and transcription settings now say where your audio is handled, such as \"On this device\", \"This browser\" or \"Your transcription server\", rather than naming the software behind them.\n- **People.** Primary buttons across People use your theme colour, and administrator screens say \"workspace\" where they used to say \"tenant\".\n- **Wording.** Labels and descriptions across Atlas, the public site and the documentation say \"and\" where they used \"+\", such as \"Goals and OKRs\". Keyboard shortcuts such as Shift + 1 are unchanged. Descriptions on Projects, Portfolios, Views, Wiki, Trash, Workspaces, the sales forecast and the shortcuts page are written in plain words.\n- **Filters.** Project status chips and Activity filters start with a capital letter, and the project status filter for everything reads \"Any status\".\n- **Reports.** Figure labels on a phone wrap onto a second line rather than being cut short.\n- **Journal.** The middle mood is now called \"Okay\". Entries you already wrote keep their mood.","date_published":"2026-10-08T00:00:00.000Z","tags":["fix"]},{"id":"1.193.8","url":"https://atlas.wrxstack.com/changelog/release-1-193-8","title":"Readable errors, full menu names and a cleaner calendar","summary":"When something fails, Atlas now says what happened in words rather than a code. Sidebar names are no longer cut short, project pickers follow your theme, and the calendar shows one view switcher.","content_text":"# 1.193.8: Readable errors, full menu names and a cleaner calendar\n\n## Fixed\n\n- **Error messages.** Screens that showed \"500\", \"HTTP 503\" or an internal address when a request failed now say what happened: that you do not have permission, that an item could not be found, or that Atlas is briefly unavailable. Contracts and eSign errors read the same way.\n- **Sidebar names.** Documents and Diagrams were cut to \"Docu...\" and \"Diagra...\" by their keyboard shortcuts. Long shortcuts now appear when you hover over the item, so every name shows in full.\n- **Client onboarding timeline.** Dates on a long timeline ran into each other. Long timelines now mark every two weeks, every four weeks or every quarter.\n- **Calendar.** Large screens showed two view switchers. They now show one, with Year, Month, Week and Day.\n\n## Improved\n\n- **Project pickers.** The project picker, used on the board, in Capture and on other screens, now opens a list in your theme rather than the system menu, and so does the booking page filter on Appointments.\n- **Wording.** Screens say \"workspace\" where they used to say \"tenant\".","date_published":"2026-10-08T00:00:00.000Z","tags":["fix"]},{"id":"1.193.7","url":"https://atlas.wrxstack.com/changelog/release-1-193-7","title":"Clearer wording across Atlas, and an accurate public changelog","summary":"Every sentence in Atlas is now written in full, with proper punctuation in place of improvised dashes, and the public changelog now shows the rewritten release notes.","content_text":"# 1.193.7: Clearer wording across Atlas, and an accurate public changelog\n\n## Improved\n\n- **Punctuation.** Sentences that used a hyphen as a dash now use a colon, a comma, a full stop or parentheses, across screens, emails, guides and the developer documentation. Date and quarter ranges read \"Jan to Mar\".\n- **Contractions.** Messages read \"could not\" and \"do not\" rather than shortened forms, and the release notes menu item is now called Latest updates.\n- **Form placeholders.** Choices such as \"Unassigned\" and \"Not specified\" read as words, without decoration.\n\n## Fixed\n\n- **Public changelog.** The release notes rewritten in 1.193.6 now appear on the public changelog too. A note an administrator has edited is never overwritten.","date_published":"2026-10-08T00:00:00.000Z","tags":["feature"]},{"id":"1.193.6","url":"https://atlas.wrxstack.com/changelog/release-1-193-6","title":"Gmail and Linear pages open again, and clearer text across Atlas","summary":"The Gmail and Linear integration pages failed to open. They work again, along with GitHub and Microsoft. Faded grey text across 27 places now meets the contrast standard, and emails and messages from Atlas are written in full sentences.","content_text":"# 1.193.6: Gmail and Linear pages open again, and clearer text across Atlas\n\n## Fixed\n\n- **Integration pages.** Opening Integrations, then Gmail or Linear, showed an error instead of the page. Two routes were answering the same address. Gmail, Linear, GitHub and Microsoft now open their own pages every time.\n- **Readable text.** Hint text, placeholders, out-of-month calendar days and several section labels were drawn fainter than the readable minimum. They now meet the WCAG AA contrast ratio in every theme.\n- **Focus time on My Work and the dashboard.** The daily focus bar now uses your theme colours, screen readers describe it as a picture of your day, and a calendar that cannot be loaded is explained in a full sentence.\n- **Release administration.** Each delete button now says which release it removes.\n\n## Improved\n\n- **Wording.** Invitation, password reset, plan change and booking emails, voice capture replies, Slack replies and rate limit messages are written in full sentences. An invitation now reads \"You will join as an owner\" instead of \"a owner\".","date_published":"2026-10-08T00:00:00.000Z","tags":["fix"]},{"id":"1.193.5","url":"https://atlas.wrxstack.com/changelog/release-1-193-5","title":"A faster API and clearer password guidance","summary":"Requests made with a personal access token now take about a third of the processing time they did, so the API answers faster under load. The messages that explain why a password cannot be used are now plain, complete sentences.","content_text":"# 1.193.5: A faster API and clearer password guidance\n\n## Improved\n\n- **API speed.** Every request made with a personal access token checked your workspace settings in a way that cost far more processing time than the check needed. It now takes a small fraction of that time, still on every request, so a change to which token permissions your workspace allows applies at once. In our load test, 50 clients listing tasks together went from 200 to 674 requests a second, and the slowest one in twenty answered in 104 ms instead of 322 ms.\n- **Task lists, search and the inbox in large workspaces.** Listing tasks, searching them and opening your notifications each read every task in the workspace on every request, so all three slowed as a workspace grew. Task lists and search now read only what they show, and the inbox checks your schedule for drift at most once every five minutes instead of on every refresh.\n- **Password messages.** When you sign up or reset a password, each reason a password is refused now reads as a full sentence. For example, a password that contains your name now says \"Do not use your name in your password.\" instead of a shortened instruction, and a request for a symbol gives examples without abbreviations.","date_published":"2026-10-08T00:00:00.000Z","tags":["improvement"]},{"id":"1.193.4","url":"https://atlas.wrxstack.com/changelog/release-1-193-4","title":"Pages no longer rebuild themselves after they appear","summary":"On about one public page load in five, the page Atlas sent was thrown away and drawn again in the browser just after it appeared. Two startup scripts were wired in a way that could make the browser wait for extra code in the middle of loading the page. They are now plain text, and the page keeps the version it first showed.","content_text":"# 1.193.4: Pages no longer rebuild themselves after they appear\n\n## Fixed\n\n- **Pages redrawn after loading.** On roughly one load in five, the page sent by the server was discarded and drawn again in the browser, which cost time and could reset what you had started to do. The scripts that set your theme and reading direction before the page paints were delivered as a reference to code the browser had to fetch first; on a slower connection that wait met a fault in the rendering library, and the whole page was redrawn. They are now delivered as plain text, and the page keeps what it first showed.","date_published":"2026-10-07T00:00:00.000Z","tags":["fix"]},{"id":"1.193.3","url":"https://atlas.wrxstack.com/changelog/release-1-193-3","title":"Every theme reads clearly, one place for notifications, and a faster first page","summary":"All 515 themes in Appearance now meet the WCAG AA contrast ratio while keeping their colours. Notifications appear in one stack, the cookie notice shows with the page instead of seconds later, and a first visit no longer logs a sign-in error.","content_text":"# 1.193.3: Every theme reads clearly, one place for notifications, and a faster first page\n\n## Fixed\n\n- **Themes.** Secondary text, links and status colours in the themes you can pick in Settings, Appearance now meet the WCAG AA ratio of 4.5 to 1. Each colour changes only in lightness, so themes keep their character; a few brand themes with a bright background deepen it slightly. On the boldest brand backgrounds, status labels show in white with their icon and word.\n- **Notifications.** Messages from different parts of Atlas could appear in two or three stacks at once, in different corners. They now share one stack of at most three. Errors stay until you dismiss them, and Escape clears the stack.\n- **Cookie notice.** It now appears with the page instead of after a request to the server, and its buttons work from the moment they can be pressed. If you have already chosen, it never shows.\n- **First visit.** Opening Atlas without an account no longer records a failed sign-in check.","date_published":"2026-10-07T00:00:00.000Z","tags":["fix"]},{"id":"1.193.2","url":"https://atlas.wrxstack.com/changelog/release-1-193-2","title":"Every colour Atlas paints now reads clearly, and screen readers hear what you see","summary":"Secondary text, the brand colour and the status colours fell short of the WCAG AA contrast ratio in the light theme, and white text on status colours failed in the dark theme. All of them now pass, and the logo links, the search button and the signup choices are named by the words on screen.","content_text":"# 1.193.2: Colours that read clearly, and names that match the screen\n\n## Fixed\n\n- **Text contrast.** Secondary text, links and labels in the brand colour, and success, warning, danger and info text on their tinted badges now meet the WCAG AA ratio of 4.5 to 1 in both themes. The light theme colours are a little deeper; the dark theme brand colour is a little lighter.\n- **Buttons and badges on a status colour.** Their text now switches with the theme instead of staying white, so a delete button is readable in the dark theme too.\n- **Reduced motion.** With reduced motion turned on in your system settings, pages now appear at once. Cards that faded in one after another used to stay invisible until their turn.\n- **Screen readers and voice control.** The Atlas logo links, the search button and the workspace choices at signup are now named by the words they show, so you can say what you see to press them. The two notification areas are told apart, and decorative parts of the logo are no longer read twice.","date_published":"2026-10-07T00:00:00.000Z","tags":["fix"]},{"id":"1.193.1","url":"https://atlas.wrxstack.com/changelog/release-1-193-1","title":"The digest shows habits at risk again","summary":"The digest's habit streak card had been showing a placeholder since habit lists became paged. It now reads every habit again and warns about streaks at risk.","content_text":"# 1.193.1: The digest shows habits at risk again\n\n## Fixed\n\n- **Habit streaks at risk.** Since habit lists became paged, the digest asked for your habits without a page and the request failed quietly, so the habit card showed a placeholder. The digest now reads every page of your habits and warns about streaks you are about to lose.","date_published":"2026-10-07T00:00:00.000Z","tags":["fix"]},{"id":"1.193.0","url":"https://atlas.wrxstack.com/changelog/release-1-193-0","title":"A security review of sign-in, assistants, webhooks and the web app, and every fix it led to","summary":"A full security review of the newest areas of Atlas found and fixed a stored script injection in task descriptions, a way to link someone else's meeting-notes account to your own, a device sign-in path open to assistants that registered themselves, and several smaller issues. Every published advisory against the packages Atlas ships is now fixed or documented as unreachable.","content_text":"# 1.193.0: A security review, and every fix it led to\n\n## Security\n\n- **Task descriptions could run script.** A tag hidden inside another tag survived the description filter and rebuilt itself, so a description could carry a framed script that ran when someone opened the task. Raw markup in descriptions is now shown as text, and a link whose address is written with character codes can no longer become a script link.\n- **Meeting-notes connections could be linked to the wrong person.** Connecting an MCP server such as Granola now finishes only in the browser that started it, so a link someone else started cannot attach your account to theirs.\n- **Assistants that registered themselves could use the device sign-in.** That flow approves every permission at once without a consent screen. It is now limited to apps Atlas registered.\n- **A device sign-in reached your oldest workspace.** It now reaches the workspace you approved it in.\n- **The sign-in consent screen could send you to any address.** Deny returned you to whatever address a link named, and an unknown app was shown under the name the link chose. An unknown app now sees an error, and Deny only returns you to an address the app registered.\n- **The web app kept a long-lived sign-in token where page scripts could read it.** It now lives only in a secure cookie the page cannot read.\n- **Addresses with secrets reached analytics and error reports.** Share links, invites and reset links are recorded as page patterns, without the secret, everywhere they are sent.\n- **Pages opened by a secret link could be indexed by search engines.** They are now marked not to be indexed.\n- **Other fixes.** AI rate limits could be stepped around with an encoded address; webhook receivers that streamed endless responses or hung could slow deliveries for everyone; a few special network ranges were missing from the webhook address check; the address recorded in the audit log, on sessions and in consent could be chosen by the caller; and sign-in tokens revoked on one server could stay valid on another during a deploy.\n- **Dependencies.** Every published advisory against a package Atlas ships is fixed, or recorded with the reason it cannot reach anyone.\n\n## Changed\n\n- **Up to 100 webhooks per workspace.** At the limit, creating one answers 409 with a limit field.\n- **Ten hosted MCP sessions per credential.** Opening another closes that credential's oldest session.\n- **The booking embed snippet now resizes the frame.** Copy it again from Settings, Booking: the old snippet never resized, and the new one accepts the height only from its own booking frame.","date_published":"2026-10-07T00:00:00.000Z","tags":["breaking"]},{"id":"1.192.0","url":"https://atlas.wrxstack.com/changelog/release-1-192-0","title":"Security updates across the web app and the API, and connected MCP servers that survive a restart","summary":"The web framework, the API server framework, the rich-text editor and more than twenty other components are updated to versions that close published security advisories, and PDF signature checks reject a forged signature format they used to accept. MCP servers a workspace connects to Atlas now stay connected when the API restarts, and thirteen screens now follow dark mode and custom themes.","content_text":"# 1.192.0: Security updates across the web app and the API, and connected MCP servers that survive a restart\n\n## Security\n\n- **Framework updates.** The web framework, the API server framework and its HTTP layer are updated to releases that close published advisories, including request-routing and header-handling issues.\n- **Component updates.** The rich-text editor, the email sender, the SAML signature checker, the XML parser, the MCP protocol library, the HTTP clients and more than twenty other components are moved to patched versions, and older vulnerable copies pulled in by other packages are replaced with the patched ones.\n- **PDF signature checks are strict.** The check that a signature matches its certificate now rejects a signature block that hides extra data, the weakness that lets a signature be forged without the signer's key. A document signed that way is reported as tampered instead of intact.\n\n## Fixed\n\n- **Connected MCP servers were forgotten on restart.** At start-up the API reads every workspace's connected MCP servers at once, and the tenant guard refused that read because no request was in progress. The read is now explicitly marked as a start-up read across workspaces, so every connection is restored.\n- **Thirteen screens ignored dark mode and custom themes in places.** Auto-schedule, Digest, Briefing, Goals, Developer apps, the agent and automation template galleries, milestones, help search, the time tracker, the read-aloud controls, calendar event cards and search highlights used colours that never changed with the theme. They now use the theme's colours, and a check stops a fixed colour from returning.\n- **The coverage check could not run.** It started before the shared packages it imports were built; it now builds them first.\n- **Five pages were missing from page analytics checks.** The MCP tools reference, its pages for each area, and the three former Super Admin email addresses, which now open the current email screens, are recorded and proven in a real browser.","date_published":"2026-10-07T00:00:00.000Z","tags":["breaking"]},{"id":"1.191.0","url":"https://atlas.wrxstack.com/changelog/release-1-191-0","title":"Connect any AI assistant to Atlas by URL, with nothing to install","summary":"Claude, ChatGPT, Cursor, VS Code and Claude Code now connect to Atlas by URL and sign in with Atlas: the assistant registers itself, you approve it on a consent screen that says what it may do, and you can end its access at any time under Settings, Connected apps. To run the server on your own machine there is no npm step: download one file from Atlas, check its checksum, and run it with Node.","content_text":"# 1.191.0: Connect any AI assistant to Atlas by URL, with nothing to install\n\n## Added\n\n- **Sign in with Atlas for AI assistants.** Add `https://api-atlas.wrxstack.com/mcp` to Claude (claude.ai, Claude Desktop and the mobile apps), ChatGPT, Cursor, VS Code or Claude Code. The assistant registers itself with Atlas, opens the Atlas sign-in and consent screen, and refreshes its own access afterwards. No token to copy.\n- **Connected apps.** Settings, Connected apps lists every assistant and app you approved: who registered it, where it returns you, how many permissions it has, and when it was connected and last active. Ending one stops it at once. The same list is at `GET /v1/connected-apps`, for a signed-in person only.\n- **A clearer consent screen.** It names what an assistant may do in plain words, shows six permissions and folds the rest, warns when an assistant registered itself, shows where you return, and follows your language and theme, including right-to-left languages and dark mode.\n- **The MCP server as one file.** `https://api-atlas.wrxstack.com/mcp/download/atlas-mcp-server.mjs`, with its SHA-256 checksum beside it, runs with Node 18.17 or later and needs no npm and no package install. Use it for a token limited to known IP addresses, a network that blocks outside connections, or a policy that asks for a local server.\n\n## Fixed\n\n- **Assistants could not register.** Registration required an Atlas administrator credential and a workspace, so no assistant could sign in. An assistant now registers itself as a public client that must use PKCE, limited to the permissions Atlas offers and owned by no workspace; a client with a secret is still registered only by Atlas.\n- **Sign-in failed at random.** A client that used its new code or token at once could find it not yet saved and be refused. Every sign-in step now answers only once its record is saved.\n- **A revoked token kept working for a moment.** Revocation now takes effect before Atlas confirms it, on every instance.\n- **Registration answered in a shape clients reject.** A public client is no longer sent an empty secret, and every OAuth error is now in the standard format clients read.\n- **An assistant asking for every permission could not be approved.** The consent step accepted at most 32 permissions; it now accepts every permission Atlas offers.\n- **The local server could exit without starting.** Started through a link, as npx and global installs do, it decided it was not the program being run and stopped silently.\n- **The MCP guide asked for npm, which never worked.** The guide, the discovery descriptor, the examples and the server help now give the URL and the single file.","date_published":"2026-10-07T00:00:00.000Z","tags":["feature"]},{"id":"1.189.0","url":"https://atlas.wrxstack.com/changelog/release-1-189-0","title":"Every webhook proven, and contracts sign end to end","summary":"A test now performs the real operation behind 177 of the 179 webhook events and confirms each one is queued for delivery. That work found and fixed nine defects, among them contracts that could not be sent for signature, signed contracts that never became active, deliverables that could not be started, and hires and CRM changes that sent no event. MCP list tools can now read every page.","content_text":"# 1.189.0: Every webhook proven, and contracts sign end to end\n\n## Fixed\n\n- **Sending a contract for signature** failed every time with a conflict. It works, and the agreement is linked to the contract.\n- **A fully signed contract becomes active.** The contract never heard that its last signature arrived, so it stayed out for signature. It now moves to signed and then active, and `contract.signed` and `contract.activated` are sent from the contract's own workspace.\n- **Starting a deliverable.** Every new deliverable was refused when someone pressed Advance. It now moves to draft, and a deliverable that has not started still cannot skip its draft.\n- **Hires send `employee.hired`** when a candidate accepts an offer and when people are added by spreadsheet import, as they already did when added by hand.\n- **The CRM API sends events.** Creating, updating and archiving accounts, contacts and deals through `/v1/crm` recorded nothing, so integrations and AI agents were never told. Winning a deal on the CRM screen now sends `crm_deal.won` and `crm_deal.stage_changed`.\n- **A PDF uploaded on the CRM screen** sends `pdf_document.created` and `pdf_document.finalized`, as one opened in the editor does.\n- **Chat file storage is given back** when a file is removed. It was counted against the workspace quota for good.\n- **Automatic replanning uses each person's own time zone** rather than UTC.\n- **Status page subscribers receive their email** when the platform is configured to send it.\n- **Contract metadata extraction runs** when the workspace has AI enabled.\n- **The last page of tasks, blog posts, blog comments, diagrams and custom fields** ends with `nextCursor: null`, instead of a cursor that led to an empty page. A page of tasks no longer ends early when private tasks fill the window it reads, and diagrams, blog comments and custom fields read one page from the database rather than every row.\n\n## Changed\n\n- **MCP list tools read every page.** Seventeen tools that read a paged list, among them `atlas_tasks_list`, `atlas_projects_list`, `atlas_habits_list` and `atlas_forms_list`, now take `cursor`. The tasks, projects, employees, pay runs and performance cycles tools accept a page of at most 100, as their routes do, rather than offering 200 and failing. Nine tools that refused a cursor over 512 characters accept every cursor their list hands back.\n- **MCP results.** The MCP guide explains structured results and how to page through a list.\n\n## Proven\n\n- **177 of 179 webhook events** fire when their operation runs through the API against a real database, each confirmed by its delivery row. `subscription.test` is sent by the test-event action, and `invoice.paid` by a payment provider callback; both have their own tests.\n- **Every MCP tool that reads a paged list** offers a cursor and sends it, held by a guard.","date_published":"2026-10-06T00:00:00.000Z","tags":["feature"]},{"id":"1.190.0","url":"https://atlas.wrxstack.com/changelog/release-1-190-0","title":"Limits each workspace can rely on, set per workspace by Super Admin","summary":"API rate limits now follow the workspace plan and are counted across every API instance. A monthly allowance of API calls is enforced for tokens and reported in response headers. Super Admin can set any workspace's rate limits, monthly allowance, daily AI spend and webhook retry policy, with a reason that is recorded in the audit log. Workspace owners can see their own limits and usage.","content_text":"# 1.190.0: Limits each workspace can rely on, set per workspace by Super Admin\n\n## Added\n\n- **Rate limits by plan.** Each workspace gets requests per minute by plan, in three classes. Free and Starter: 300 reads, 60 writes and 20 AI calls. Pro, Team and Business: 1,200 reads, 300 writes and 60 AI calls. Enterprise: 6,000 reads, 1,500 writes and 300 AI calls. A workspace whose subscription has lapsed uses the free limits. Every answer carries `X-RateLimit-Tier` beside the existing rate-limit headers.\n- **Limits shared across instances.** The per-minute count is kept in the shared store, so a workspace gets the same limit however many API instances serve it.\n- **A monthly allowance of API calls.** Calls made with a personal access token or an OAuth token count against the workspace's monthly allowance, which starts again at the beginning of each calendar month in UTC. Each answer carries `X-Quota-Limit`, `X-Quota-Remaining` and `X-Quota-Reset`. A call past the allowance is refused with `429`, the error type `quota-exceeded`, `Retry-After`, and the period, limit, calls used and reset time. Calls made from the Atlas apps do not count.\n- **Super Admin sets limits for one workspace.** The workspace page in Super Admin sets reads, writes and AI calls per minute, the monthly allowance, the daily AI spend, and the webhook policy: attempts (1 to 12), the wait before each retry (10 seconds to 72 hours) and the time a receiver has to answer (1 to 30 seconds). Each change requires a reason and is recorded in the audit log with the old and new value of every field. A value of 0 per minute stops that class of calls during an incident, and clearing a field returns it to the plan. Changes take effect within 30 seconds on every instance. The same controls are available through `GET` and `PUT /super-admin/tenants/{tenantId}/limits` and the tools `atlas_super_admin_workspace_limits_get` and `atlas_super_admin_workspace_limits_update`.\n- **Workspace owners see their limits.** Settings, API access, shows the workspace's monthly allowance, daily AI spend and webhook policy, and the calls used this month, beside its per-minute limits. Owners and admins can read the same view at `GET /v1/workspace/limits` and with `atlas_workspace_limits_get`.\n- **Form 941.** `GET /v1/hr/statutory/form941?year=&quarter=` prepares the quarterly federal return from the quarter's United States payslips, and `atlas_payroll_statutory_form941_url_get` returns its link. A quarter with no United States payslips is refused with `form941-no-us-payslips`.\n- **Engagement finance for AI agents.** Seven MCP tools read an engagement's commercial terms, budgets, burn, profitability, financial snapshots, delivery metrics and subcontractors.\n- **Events for each operation.** Each operation in the API reference lists the webhook events it sends, taken from the test that runs it against a real database.\n- **Obligations by contract.** The obligations list, its API and its MCP tool take `contractId`.\n\n## Fixed\n\n- **The API failed to start after every update since 29 September,** so no API change since then reached production. The automation engine read a class that was still loading during start-up. Four services that defer a dependency now describe it so it is never read early, and a guard keeps it that way.\n- **The documentation site failed to build** because one code sample on the MCP page named a language its component does not accept.\n- **The daily AI spend cap follows the plan.** Every workspace without its own cap was held to 50,000 cents a day, the free cap, whatever its plan. The cap enforced is now the one the workspace is entitled to, and the one Settings and Super Admin show.\n- **Quota caps no longer keep a copy of an old plan.** Changing a workspace's plan or features in Super Admin copied the plan's caps into the workspace, so a later plan change left the old caps in force. A plan change now returns the caps to the new plan, other changes leave them alone, and copies already stored at or below the current plan are cleared. A cap someone set on purpose is kept.\n- **Rate limits follow the same plan families as everything else.** Starter is a Free plan and Scale is a Business plan, as the entitlement catalogue has them.\n- **Super Admin quota overrides were lost on restart.** They were held in the memory of one instance, so they did nothing on the others and disappeared on the next deploy. They are now stored with the workspace.\n- **Resetting a workspace's rate limit in Super Admin** reported 0 keys cleared and did not wait for the reset to finish.\n- **Business plans were given the free rate limits.** They now get the Pro limits.\n- **Three operations were missing from the OpenAPI document:** reading email templates, and reading and saving workspace branding. Two routes shared an operation name, and one hid the other.\n- **A contract whose signature request failed** left its agreement open. The agreement is now voided, so the contract can be sent again.\n- **Publishing changes in the Growth Suite** record their audit entry in the same transaction as the change, as do the other writes that send a webhook event. An entry is never recorded for a change that did not happen.\n- **The generated Python, Go and Ruby clients** called `/v1/v1`. Their base URL is now the host, as each path already starts with `/v1`.\n\n## Changed\n\n- **Webhook deliveries follow the workspace policy.** Each delivery records the attempts it is allowed, and every attempt is traced.\n- **150 generated MCP route tools retired.** Each called a route that a dedicated tool already covers. The dedicated tools remain.\n- **Removed:** a second, outdated copy of the OpenAPI document, an unused webhook dispatcher, and an in-memory dead-letter queue that nothing read. The API serves the one OpenAPI document at `/v1/openapi.json`.","date_published":"2026-10-06T00:00:00.000Z","tags":["feature"]},{"id":"1.187.0","url":"https://atlas.wrxstack.com/changelog/release-1-187-0","title":"An assistant can reach almost all of Atlas","summary":"Atlas gains 676 MCP tools across client delivery, chat, service operations, client onboarding, workspace administration, automations and connected services, and every read tool is proven against the real API. That proof found and fixed custom email templates, focus coaching, project risk rollups and the workspace list, which failed for everyone.","content_text":"# 1.187.0: An assistant can reach almost all of Atlas\n\n## Added\n\n- **676 MCP tools** for client delivery, chat, service operations, client onboarding, workspace administration, automations and connected services. An assistant can now read and work with engagements and their plans, risks, requests, governance and finances; chat channels, files and channel documents; incidents, services, problems and reviews; onboardings; roles and workspace settings; automation runs and versions; and GitHub, Slack, Notion, HubSpot, Gmail, Google Calendar, Google Drive, Stripe and Microsoft 365. Tools that would sign off, message a customer, change who is paged, or create or reveal a credential are left out on purpose.\n- **Every read tool is proven against the real API.** A test calls each of the 295 read tools that need no input through the real server and database, and fails on any answer other than a correct one.\n\n## Changed\n\n- **A connected service that is not connected answers 409, not 401.** Old: `401` with a short message. New: `409` with type `https://atlas.dev/errors/connector-not-connected` and the `connectorId`; a grant that has expired and cannot be renewed answers `409` with type `https://atlas.dev/errors/connector-reconnect-required`. Affects every `/v1/connectors/*` operation and the connection test routes. Your token is fine in both cases, so do not refresh it.\n- **Project risk rollups need a project.** `GET /v1/project-risks/rollup`, `GET /project-risks/rollup` and `GET /project-risks/raid-rollup` now answer `422` when `projectId` is missing. They failed with `500` before.\n- **Email A/B test list.** Old: `{ items }`. New: `{ items, nextCursor }`, like every other list. Affects `GET /v1/email-ab-tests`.\n- **MCP tools.** `atlas_payroll_payslips_form24q_url_get` is now `atlas_payroll_statutory_form24q_url_get`; it takes `fy` and `quarter` and returns the path of the quarterly Form 24Q return. `atlas_docs_api_reference_get` returns the paths of the reference, the OpenAPI document and the Postman collection instead of following a redirect. `atlas_time_entries_export` returns `{ contentType, body }` with the CSV text. `atlas_projects_risks_rollup_get` requires `projectId`. Route tools for CSV, PDF and calendar routes return the path to download the file.\n\n## Fixed\n\n- **Custom email templates and A/B tests.** Saving a custom email template, and listing email A/B tests, failed every time. Both work, and a variant or an event can no longer point at another workspace template.\n- **Focus coaching suggestions** failed every time and now work.\n- **My workspaces** (`GET /v1/workspaces/mine`) failed every time and now lists the workspaces you belong to.\n- **Billing invoices** include the invoices issued by the payment provider.\n- **A webhook is never sent for a change that was undone.** An event recorded inside a change that then failed could still be sent; it is now sent only once the change is saved.\n- **Diagram usage for a past date range** with the start after the end showed nothing once the end was more than 30 days ago; it now shows the 30 days before the end.\n\n## Webhook retries\n\n- The third wait is now 10 minutes, so a failed delivery is retried after 30 seconds, 2 minutes, 10 minutes, 30 minutes, 2 hours, 8 hours and 24 hours.\n- A `Retry-After` header on a `429` or `503` is honoured, up to 24 hours. It can hold a retry back but never bring one forward.","date_published":"2026-10-05T00:00:00.000Z","tags":["feature"]},{"id":"1.188.0","url":"https://atlas.wrxstack.com/changelog/release-1-188-0","title":"Every list pages, and every error says what went wrong","summary":"Seventy-eight lists now return one page at a time with a cursor, so a large workspace never times out or truncates. Every error names its kind with a stable type and code, a token caller gets idempotent retries and rate-limit headers on every route, MCP tools return structured results, and the developer documentation gains a full MCP tools reference, search across every operation, tool and event, and Go and Ruby samples.","content_text":"# 1.188.0: Every list pages, and every error says what went wrong\n\n## Added\n\n- **Paging on 78 lists.** Each list takes `limit` (1 to 100, 50 by default), `cursor`, `sort` and `order`, and answers `{ items, nextCursor }`. Pass `nextCursor` back as `cursor` for the next page; it is `null` on the last page. The cursor is opaque and can be up to 4,096 characters, because it carries the sort value of the last row.\n- **Idempotent retries and rate limits for every token caller.** A personal access token or OAuth token can now send `Idempotency-Key` on any write it can make, not only on the routes built for the public API, and every answer to a token carries `X-RateLimit-Limit`, `X-RateLimit-Remaining` and `X-RateLimit-Reset`.\n- **MCP tools reference.** `/docs/mcp/tools` lists all 1,640 tools in 58 areas with the scope each needs, its arguments, the operation it calls and an example prompt. Each API operation in the reference links to the tools that call it.\n- **Search across the developer documentation.** The docs search finds any of the 2,498 API operations, 1,640 MCP tools and 178 webhook events by name.\n- **Go and Ruby samples** for every operation in the API reference, beside curl, TypeScript and Python. Every sample and response is highlighted, and every operation, tool and event has a link you can copy.\n- **Examples in the OpenAPI document.** Every JSON request and success response that has a schema now has an example, so the reference, the Postman collection and generated clients all show a concrete value.\n- **Load more** on the data residency audit, the data processing requests and consent records, the security event export deliveries and the access audit.\n\n## Changed\n\n- **Lists answer one page.** Old: every row, or `{ items }` with every row. New: `{ items, nextCursor }` with at most 100 rows. Affects habits, goals, project objectives, focus sessions, time entries, booking pages and bookings, forms, quick links, recent items, daily notes, journal reviews, templates and task templates, saved filters, task relations, board columns, groupings, formula fields, undo history, reports and report deliveries, wiki pages, inbound email, contracts, CRM accounts, contacts, deals, playbooks and win-loss records, Growth Suite records, custom roles, agent governance, audit export presets, security event export deliveries, retention policies, release notes, profile lists and workload capacity. Read every page with `collectAllPages` from `@atlas/client`.\n- **Smaller page limits.** Focus sessions accepted up to 500 rows a request and daily notes up to 60; both now take 1 to 100.\n- **Goals are ordered by when they were created.** Old: by kind, then by creation. New: by creation, oldest first; pass `sort` and `order` to change it.\n- **Errors name their kind.** Old: `type` was `about:blank`, with `statusCode` and `error` fields. New: `type` is a stable address under `https://atlas.dev/errors/`, such as `validation`, `not-found` or `rate-limited`, with a `title`, a `detail` and, where Atlas knows more, a `code` such as `task-not-found`. `statusCode` and `error` are gone; read `status`. An expired token answers `401` with type `https://atlas.dev/errors/token-expired`, so a client knows to refresh rather than sign in again. A stale `If-Match` answers type `https://atlas.dev/errors/conflict` with code `version-conflict`, and the readiness check answers `503` with `state: \"degraded\"` beside the numeric `status`.\n- **MCP tool results.** A tool that returns a list returns `{ items }` as structured content, and any other value returns `{ value }`. A failed call returns a structured error with `type`, `title`, `detail` and, from the API, `code` and `requestId`. Every prompt has a title.\n- **MCP paging.** The list tools for templates, task templates, reports, workload capacity, direct reports, habits, goals, focus sessions, time entries, forms, recent items, daily notes, journal reviews, CRM and contracts take `limit`, `cursor`, `sort` and `order`.\n\n## Fixed\n\n- **The notes sidebar** asked for 100 notes from a route that allowed 60, so it failed to load. It loads.\n- **The mobile templates screen** counted only the first page, and counted task templates as project templates. It counts every project template and every task template.","date_published":"2026-10-05T00:00:00.000Z","tags":["feature"]},{"id":"1.170.0","url":"https://atlas.wrxstack.com/changelog/release-1-170-0","title":"Webhooks: one system, one envelope, and a signature that resists replay","summary":"Every webhook, whether created through the API or in Settings, is now sent by one delivery system, in one documented envelope, with one signature scheme. Each event carries the resource exactly as the API returns it, and each attempt is signed with a timestamp so a captured delivery cannot be replayed.","content_text":"# 1.170.0: Webhooks\n\n## What changed\n\n- **One webhook system.** Webhooks created with `/v1/webhooks` and webhooks created in Settings, then Webhooks, are now the same thing. Each appears in both places, and one delivery worker sends them all.\n- **One envelope.** Every event has the shape `{ id, type, apiVersion, createdAt, tenantId, actor, data }`. `data.object` is the resource as a `GET` returns it, and an update adds `data.previousAttributes` with the earlier value of each changed field.\n- **One signature.** `Atlas-Signature: t=<seconds>,v1=<hex>`, where each `v1` is the HMAC-SHA256 of `<t>.<raw body>`. Every attempt is signed when it is sent, so a receiver can refuse a timestamp more than five minutes old.\n- **Rotation without a gap.** After a rotation both secrets sign every delivery for 58 hours and 45 minutes, and the response states when the old secret stops.\n- **A longer, clearer retry schedule.** Eight attempts, after 30s, 2m, 8m, 30m, 2h, 8h, and 24h. A `4xx` other than `408` or `429`, and any redirect, is final. A delivery that runs out of attempts is kept and can be replayed.\n- **The event catalogue is enforced.** A webhook can subscribe only to published events, a resource wildcard such as `task.*`, or `*`. A misspelt event name is refused when the webhook is saved.\n\n## Changes to existing behaviour\n\nThese change what a receiver built for `/v1/webhooks` receives. Update your receiver before this release reaches your workspace; the guide at `/docs/webhooks/security` has verified code in five languages.\n\n- **Headers.** `x-atlas-webhook-signature`, `x-atlas-webhook-timestamp`, `x-atlas-webhook-id`, `x-atlas-webhook-key-version`, `x-atlas-event`, `x-atlas-delivery`, and the body-only `x-atlas-signature` are no longer sent. Use `Atlas-Signature`, `Atlas-Timestamp`, `Atlas-Event-Id`, `Atlas-Event-Type`, `Atlas-Delivery-Id`, and `Atlas-Subscription-Id`.\n- **Body.** The flat `{ id, tenantId, action, target, actorId, actorKind, context, at }` body is replaced by the envelope above.\n- **The test event** is now `subscription.test`, and `POST /v1/webhooks/{id}/test-delivery` returns `{ accepted, action }`.\n- **Rotation** returns `{ id, signingKeyVersion, secret, previousSigningKeyExpiresAt }`.\n- **Field name.** A webhook's `lastDelivery` is now `lastDeliveryAt`.\n\n## Fixed\n\n- **Webhooks lost on restart.** A `/v1` webhook was held in memory by the process that registered it and stopped delivering whenever the API restarted. Every webhook is now stored and delivered from the database.\n- **A replay repeated the event under a new id.** A replayed delivery now carries the original event id, so a receiver that skips events it has processed also skips the replay.\n- **Next retry times.** The delivery log showed retry times from an older schedule. It now shows the schedule the worker runs.\n- **The OpenAPI document** described fields `/v1/webhooks` never returned. It now matches every response, and a test holds it there.","date_published":"2026-09-29T00:00:00.000Z","tags":["breaking"]},{"id":"1.171.0","url":"https://atlas.wrxstack.com/changelog/release-1-171-0","title":"Booking webhooks join the one webhook system, and host booking changes work again","summary":"Webhooks made from a booking page are now ordinary Atlas webhooks, scoped to their page, delivered in the documented envelope with the booking exactly as the API returns it. A guest moving a booking now sends an event too. Cancelling, rescheduling and reminding from the host side, which failed with a server error, work again.","content_text":"# 1.171.0: Booking webhooks\n\n## What changed\n\n- **One system.** A webhook made from a booking page is an Atlas webhook that hears only that page, and a workspace-wide booking webhook is one that hears every page. Both appear in Settings, then Webhooks, as well as on the booking page, and are sent by the same delivery worker as every other webhook.\n- **Three new catalogue events.** `booking.created`, `booking.cancelled` and `booking.rescheduled` can be chosen by any webhook, including through `/v1/webhooks`. Each carries the booking in `data.object`, in the shape `GET /v1/appointments/{id}` returns, which the OpenAPI document now describes as `Appointment`.\n- **A guest moving a booking is an event.** Rescheduling through the link in the confirmation email now sends `booking.rescheduled`. It used to send nothing.\n- **The Test button** sends a `subscription.test` event at once and shows what your endpoint answered.\n- **Secrets are encrypted at rest.** Booking webhook secrets were stored as plain text. They are encrypted the next time the API starts.\n\n## Changes to existing behaviour\n\nA receiver built for booking webhooks must be updated before this release reaches your workspace.\n\n- **Headers.** `x-atlas-event`, `x-atlas-signature: sha256=...`, `x-atlas-delivery` and `x-atlas-attempt` are replaced by `Atlas-Signature: t=<seconds>,v1=<hex>` and the other `Atlas-*` headers described at `/docs/webhooks/payloads`.\n- **Body.** `{ event, deliveredAt, data }` is replaced by the documented envelope. The booking is in `data.object`.\n- **Retries** follow the Atlas schedule: eight attempts over about 35 hours, where booking webhooks used six over about nine hours.\n- **A booking webhook needs at least one event.** A list with none is refused; leaving the list out subscribes to all three.\n\n## Fixed\n\n- **Webhooks were queued and never sent.** Nothing started the worker that sends queued deliveries, so every webhook event waited in the queue. It now starts with the API, and a test fails if any scheduled loop is ever left unstarted again.\n- **Host cancel, reschedule and reminder returned a server error.** Each emails the guest, and the email read the host profile in a way the database refuses. They work again, and so does the email for a booking made with a meeting type.\n- **A new member did not appear in the member list for up to a minute** after accepting an invite. The list now updates at once.\n- **A booking page of another workspace** could be named when creating a booking webhook. It is now treated as not found.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.172.0","url":"https://atlas.wrxstack.com/changelog/release-1-172-0","title":"Webhooks: a failing webhook is paused, and you are told","summary":"When every delivery to a webhook has failed for three days, Atlas pauses it and emails its escalation contact, or the workspace owners and administrators. The webhook settings screen shows the pause, explains it, and turns the webhook back on in one step.","content_text":"# 1.172.0: Paused webhooks\n\n## What changed\n\n- **Automatic pause.** A webhook whose every delivery has failed for three days, counted from the first failure after its last success, is paused. Nothing more is sent to it until it is turned back on.\n- **A notice by email.** The escalation contact on the webhook is emailed, or, without one, every owner and administrator of the workspace. The email names the webhook, its address, the last answer from the endpoint, and when the failures began.\n- **Shown where you manage it.** Settings, then Webhooks, marks the webhook Paused and explains why, with a button that turns it back on. Every webhook can now be turned on and off from its panel.\n- **In the API.** `/v1/webhooks` returns `pausedAt`, and the settings API returns `pausedAt` and `pausedReason`. Setting `disabled` to false, or `active` to true, resumes the webhook and clears both.\n- **Recorded.** Each pause is written to the audit log as `webhook.auto_paused`.\n\n## Fixed\n\n- **The SIEM export missed most of the audit log.** Actions recorded in the sealed audit log, which include every HR change, never reached the SIEM export. They now do. Automations are unchanged: each change still runs a matching automation once.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.173.0","url":"https://atlas.wrxstack.com/changelog/release-1-173-0","title":"Webhooks for HR, CRM, meetings, the wiki, diagrams and more","summary":"Fifty-three new webhook events cover people and hiring, payroll, CRM accounts, contacts and deals, teams, time approvals, meetings, the knowledge base, diagrams, PDF conversions, client onboarding, comments and tasks. Each carries the record exactly as the API returns it.","content_text":"# 1.173.0: More webhook events\n\n## What changed\n\n- **Fifty-three new events**, bringing the catalogue to eighty-one. They are listed, with what each means, at `/docs/webhooks/events` and when you create a webhook.\n- **People, hiring and payroll events are sent only when you ask for them by name.** `employee.*`, `candidate.*`, `job_application.*`, `job_offer.*`, `payroll_run.*` and `hr_ticket.*` carry personal or pay data, so a webhook subscribed to every event with `*` does not receive them. Name the event, or its resource wildcard, to receive it.\n- **Every event carries its record** as the matching API read returns it, loaded when the event is sent.\n\n## Fixed\n\n- **The sealed audit log recorded nothing.** The tamper-evident log that routes such as HR, comments and automations write to ran outside the request it belonged to, so it wrote no rows and read no earlier values. It now records every change, sealed into its hash chain, with the value each field had before an update.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.174.0","url":"https://atlas.wrxstack.com/changelog/release-1-174-0","title":"Webhooks for contracts and eSign agreements","summary":"Sixteen new webhook events follow a contract from creation through approval, signature, activation, renewal and termination, and an eSign agreement from sending to completion. Each carries the record exactly as the API returns it.","content_text":"# 1.174.0: Contract and eSign webhooks\n\n## What changed\n\n- **Nine contract events**: `contract.created`, `contract.updated`, `contract.approved`, `contract.declined`, `contract.sent`, `contract.signed`, `contract.activated`, `contract.terminated` and `contract.renewed`.\n- **Seven eSign events**: `esign_agreement.sent`, `esign_agreement.viewed`, `esign_agreement.signed`, `esign_agreement.declined`, `esign_agreement.voided`, `esign_agreement.completed` and `esign_agreement.expired`. A signer acting from an emailed link is reported as a system actor.\n- **The catalogue now holds ninety-seven events.** They are listed, with what each means, at `/docs/webhooks/events` and when you create a webhook.\n- **Each event is sent once**, after the change is saved, from the tamper-evident trail each contract and agreement already keeps.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.175.0","url":"https://atlas.wrxstack.com/changelog/release-1-175-0","title":"Webhooks for members, invites, announcements and project planning","summary":"Seventeen new webhook events report people joining, changing role in and leaving the workspace, invites sent and revoked, workspace announcements, and project milestones and status updates. Joining a workspace from an invite is now recorded in the audit log.","content_text":"# 1.175.0: Member, invite, announcement and planning webhooks\n\n## What changed\n\n- **Members and invites**: `workspace_member.joined`, `workspace_member.role_changed`, `workspace_member.removed`, `workspace_invite.created` and `workspace_invite.revoked`. A role change carries the earlier role in `previousAttributes`, and a removal carries who the person was, so another system can remove their access too.\n- **Announcements**: `announcement.created`, `announcement.updated`, `announcement.published`, `announcement.unpublished` and `announcement.deleted`, for announcements your workspace writes. Announcements from Atlas itself are not sent.\n- **Project planning**: `project_milestone.created`, `project_milestone.updated`, `project_milestone.status_changed`, `project_milestone.deleted`, `project_status_update.created`, `project_status_update.updated` and `project_status_update.deleted`.\n- **Three new reads**: `GET /tenants/members/{userId}`, `GET /tenants/invites/{id}` and `GET /v1/announcements/admin/{id}` return one record, in the shape the events carry. An invite now states its `status`: pending, accepted, revoked or expired.\n- **The catalogue now holds one hundred and fourteen events.**\n\n## Fixed\n\n- **Joining a workspace left no record.** Accepting an invite added the person without an entry in the audit log. It is now recorded.\n- **The API reference said `*` receives every event.** People, hiring and payroll events are sent only to a webhook that names them, and each of those events now says so.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.176.0","url":"https://atlas.wrxstack.com/changelog/release-1-176-0","title":"Webhooks for leave, expense claims, performance reviews and changes of role","summary":"Fifteen new webhook events cover leave requests, reimbursement claims, performance reviews and changes of role. Like the other people events, they are sent only to a webhook that names them.","content_text":"# 1.176.0: Leave, claim, review and role change webhooks\n\n## What changed\n\n- **Leave**: `leave_request.requested`, `leave_request.approved` and `leave_request.rejected`. A request its policy approves automatically arrives already approved.\n- **Expense claims**: `reimbursement_claim.created`, `reimbursement_claim.submitted`, `reimbursement_claim.approved`, `reimbursement_claim.rejected` and `reimbursement_claim.paid`, whether the employee or HR filed the claim.\n- **Performance reviews**: `performance_review.created`, `performance_review.updated` and `performance_review.finalized`. A review now also returns `finalizedAt`, `selfRating`, `managerRating` and `finalRating`, so a review finalized through the review workflow carries its result.\n- **Changes of role**: `role_change.requested`, `role_change.manager_approved`, `role_change.applied` and `role_change.rejected`.\n- **Sent only when named.** These carry personal or pay data, so a webhook subscribed to `*` does not receive them. Name the event, or its resource wildcard such as `leave_request.*`.\n- **Four new reads**: `GET /v1/hr/leave/requests/{id}`, `GET /v1/hr/reimbursements/claims/{id}` (owners and administrators), `GET /v1/hr/performance/reviews/{id}` and `GET /v1/hr/role-changes/{id}`.\n- **The catalogue now holds one hundred and twenty-nine events.**","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.177.0","url":"https://atlas.wrxstack.com/changelog/release-1-177-0","title":"Webhooks for task attachments and automation runs, and form submissions as tasks","summary":"Four new webhook events report files attached to and removed from tasks, and every automation run, with a separate event for runs that fail. A public form submission now counts as a created task for webhooks and automations.","content_text":"# 1.177.0: Attachment and automation run webhooks\n\n## What changed\n\n- **Task attachments**: `task_attachment.added` and `task_attachment.deleted`. The event carries the file name, type and size, never a link to the file.\n- **Automation runs**: `automation_run.completed` after every run, and `automation_run.failed` as well when any step failed. Subscribe to the second alone to hear only about failures.\n- **Two new reads**: `GET /tasks/{taskId}/attachments/{attachmentId}` and `GET /automations/{id}/runs/{runId}`.\n- **The catalogue now holds one hundred and thirty-three events.**\n\n## Fixed\n\n- **A form submission was invisible to webhooks and automations.** Submitting a public form created its task without recording it, so no `task.created` webhook was sent and no automation on new tasks ran. It is now recorded, as a system action.\n- **An automation can never set itself off.** The record of a run does not start another run, so an automation that listens to every event cannot loop on its own runs.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.178.0","url":"https://atlas.wrxstack.com/changelog/release-1-178-0","title":"MCP: fifty-seven broken tools repaired, tool hints, resources and new prompts","summary":"Fifty-seven MCP tools called a route that does not exist and failed every time; all but one are repaired, and a new check stops it happening again. Every tool now tells your AI host whether it only reads or cannot be undone, results come back as structured data, and six new prompts cover pipeline reviews, leave, incidents, delivery status, renewals and notifications.","content_text":"# 1.178.0: MCP repairs, hints, resources and prompts\n\n## Fixed\n\n- **Fifty-seven MCP tools failed on every call.** They called routes the API does not serve, most by adding a `/v1` prefix to a route mounted without one. Fifty-six now call the right route, and a check compares every route a tool calls with the routes the API serves. The last, `atlas_pdf_studio_run_tool`, has no route that could serve it and awaits a decision on its removal.\n- **`GET /v1/webhooks/{id}` is new**, so `atlas_get_webhook` works.\n- **Failures after retries kept their explanation.** A 5xx or 429 answer that used up its retries lost its body; the problem the API returned is now passed on.\n\n## What changed\n\n- **Tool hints.** Every tool has a title and says whether it only reads, whether its change cannot be undone, and whether repeating it is safe. Hosts use this to decide when to ask you first.\n- **Structured results and errors.** A single-object result comes back as structured data as well as text, and an API failure keeps its title, detail and type.\n- **Resources.** Attach yourself, a task, a project, a CRM account, a wiki page or a service incident to a conversation without a tool call.\n- **Six new prompts**: CRM pipeline review, HR leave triage, incident summary, weekly delivery status, contract renewal review and inbox triage. The five existing prompts are rewritten to call tools with arguments they accept.\n- **Contract steps.** `atlas_contracts_transition_status` offers the steps the API serves, and takes `comment` where it took `reason`. **Slack links.** `atlas_set_project_slack` now needs the installation id and the channel name to link a channel.\n- **Status page tools** belong to the Super Admin MCP server, the only credential their routes accept.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.179.0","url":"https://atlas.wrxstack.com/changelog/release-1-179-0","title":"MCP: seventy-six tools now send what the API accepts, and the API stays up when its cache is unavailable","summary":"Seventy-six MCP tools sent field names or filters their API routes do not read, so they failed on every call or reported success while changing nothing. They now send exactly what each route accepts, checked by a guard and by an end-to-end suite that drives every area of Atlas through MCP against a real database. Requests no longer hang when the cache server is unreachable.","content_text":"# 1.179.0: MCP tools that do what they say\n\n## Fixed\n\n- **Fifty-nine tools sent the wrong body.** Most were in HR, hiring, payroll, performance and CRM. `atlas_create_employee` sent `email` and `hireDate` to a route that reads `workEmail` and `joinedAt`, so it always failed; `atlas_update_employee` sent `jobTitle`, which the route discards, so it reported success and changed nothing. Each now takes the route's own field names, and inputs the route has no place for are gone rather than silently dropped.\n- **Fourteen list tools sent filters the routes ignore**, so a filtered list came back unfiltered. They now send the filters each route reads, and the project dependency and RAID tools ask for the project they need.\n- **`atlas_create_project` never sent a team** and always failed. It now uses the workspace's only team, or asks which team when there are several.\n- **One tool schema made strict MCP clients reject the whole tool list.** Every input schema is now an object at the top, as the protocol requires.\n- **Requests hung while the cache server was unreachable.** Cached reads, shared rate limits and presence now fall back at once instead of waiting.\n\n## Changed\n\n- Tool inputs renamed to match the API include `workEmail`, `joinedAt`, `jobOpeningId`, `compensationAnnualCTC`, `toStage`, `recordKind` and `recordId`, and several tools now require fields their route always required. The MCP changelog lists every tool and field.\n- `atlas_agreements_create_from_template` cannot work, because the route needs the PDF itself, and awaits a decision on its removal.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.180.0","url":"https://atlas.wrxstack.com/changelog/release-1-180-0","title":"MCP documentation names the scopes each tool really needs","summary":"The MCP reference and the discovery descriptor now show, for every tool, a scope its API routes accept, read from the routes rather than written by hand. Hundreds of entries named scopes that do not exist, so a token minted from the documentation could not call the tool.","content_text":"# 1.180.0: Real scopes in the MCP reference\n\n## Fixed\n\n- **Documented scopes that do not exist.** Entries in the MCP reference named scopes such as `governance:write` or `habits:view`, which no token can hold, or `none` for tools whose routes require a scope. Every entry now names a scope the tool's routes accept, space separated when a tool calls more than one route, and a check fails when an entry drifts.\n- The written MCP reference and the package README use the same scopes.\n\n## Known\n\n- Thirty-nine tools call a route that accepts no token, such as managing access tokens, blog administration and AI provider settings, so no MCP caller can use them. They are listed and held until a decision on their removal.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.181.0","url":"https://atlas.wrxstack.com/changelog/release-1-181-0","title":"MCP lists only the tools a token can use","summary":"Forty-one MCP tools are removed because no caller could use them: they called routes that refuse every access token, or routes that do not exist. Every remaining route bridge documents a scope its route accepts, read from the API itself.","content_text":"# 1.181.0: Only usable MCP tools\n\n## Removed\n\n- **Forty-one tools that failed on every call.** They covered managing access tokens, workspace sign-in settings, model provider readiness and usage, report share links, blog administration, marketplace developer apps and push receipts. The routes behind them accept a signed-in session only, so an MCP caller holding a token was always refused. Two more, a generic PDF operation and creating an agreement from a template, called operations with no route. The MCP changelog lists every removed tool.\n\n## Fixed\n\n- **Scopes on route bridges.** Each generated route bridge now names a scope its route accepts, read from a manifest generated from the API routes, and the generator never offers a route that refuses every token.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.182.0","url":"https://atlas.wrxstack.com/changelog/release-1-182-0","title":"MCP tools follow one naming pattern","summary":"Every hand-written MCP tool is now named for its product area, the thing it acts on and its action, in that order, so a model can tell tools apart by the position of each word. 908 tools are renamed in place, and the MCP changelog lists every old name beside its new one.","content_text":"# 1.182.0: One naming pattern for MCP tools\n\n## Changed\n\n- **Tool names.** Every hand-written tool is named `atlas_<area>_<resource>_<verb>`: `atlas_list_tasks` is now `atlas_tasks_list`, and approving a leave request is `atlas_hr_leave_requests_approve`. 908 tools are renamed and 89 already followed the pattern. The old names are gone, with no aliases, so a saved prompt or host configuration that names a tool needs the new name. The MCP changelog lists every old name beside its new one.\n- **Tool titles** read verb first and are derived from the new names, for example \"Approve HR leave requests\".\n- **The MCP documentation** explains the pattern, and a check fails on any tool name that does not follow it.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.183.0","url":"https://atlas.wrxstack.com/changelog/release-1-183-0","title":"Every list returns items and a cursor, and webhooks recover lost events","summary":"All 107 API lists that returned a bare array now return { items, nextCursor }, as the rest of the API does. Every request body is checked before it reaches a service, a webhook event lost between a change and its delivery is now recovered, and MCP route tools take the fields their route accepts.","content_text":"# 1.183.0: Consistent lists and recovered webhook events\n\n## Changed\n\n- **Lists.** 107 list endpoints, among them CRM accounts, contacts and deals, contracts, goals, habits, forms, time entries, workload, wiki pages, saved views, templates and the Growth Suite records, returned a bare JSON array. Each now returns `{ \"items\": [...], \"nextCursor\": null }` with the same rows. An integration that reads the array directly must read `items`. The web and mobile apps are updated in this release, and the desktop app and browser extension already read the new shape.\n- **Request bodies.** Twenty-six routes, among them booking pages, meeting types, questions and blackouts, voice capture, compliance packs, offer decisions and focus coaching, passed any JSON to the service. Each now validates its body and answers a clear validation error for a missing or malformed field.\n\n## Added\n\n- **Recovered webhook events.** Atlas records every change before it sends the webhook. If a delivery was not queued, for example because a server restarted between the two, Atlas finds the change within a minute and queues it with its original event id. A new or edited webhook never receives events from before it existed.\n- **Typed MCP route tools.** A generated route tool now takes exactly the body and query fields its route validates, so an assistant sees the real field names and invalid input is refused before any request is sent. Every request a tool makes names the tool, and tools can declare the shape of what they return.\n\n## Fixed\n\n- The goals tree and goal detail screens, and the mobile saved views and templates screens, would have shown an empty list after this change; they now read the new shape.\n- The public integrations guide for AI providers now describes what a workspace administrator does, without the deployment details behind it.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.184.0","url":"https://atlas.wrxstack.com/changelog/release-1-184-0","title":"Your own AI key, checked, and used everywhere","summary":"A workspace that brings its own AI key now has it checked with the provider when it is saved, and every AI feature uses it. An administrator decides whether Atlas may use its default provider when the key cannot be used, and the settings show which mode is active.","content_text":"# 1.184.0: Your own AI key, checked and used everywhere\n\n## Added\n\n- **Key check.** Saving your own key for Anthropic, OpenAI, Google Gemini or Azure OpenAI now asks the provider to confirm it. A key the provider rejects is not saved, and the settings say why.\n- **Fallback switch.** In Settings, then AI Providers, an administrator decides whether Atlas may use its default provider when the workspace key cannot be used. It is off unless the workspace had already listed the Atlas default in its fallback order. With it off, an AI feature whose key fails says so instead of running elsewhere.\n- **Active mode.** The settings show whether the workspace uses the Atlas default, its own key and which provider, or a local runtime, and whether fallback is on.\n\n## Changed\n\n- **Every AI feature follows the workspace choice.** Diagram AI, contract analysis, PDF intelligence, PDF questions and meeting insights now use the workspace key and model like the other AI features, and record usage against the workspace. Creating a diagram from an image runs only where the workspace allows the Atlas default.\n- **Keys are managed in one place.** Setting or removing a key now needs a signed-in administrator; an access token can no longer do it.\n\n## Fixed\n\n- A workspace using its own OpenAI key could send its fallback requests with that same key. Fallback now uses its own credentials, and only when allowed.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.185.0","url":"https://atlas.wrxstack.com/changelog/release-1-185-0","title":"Workspace boundaries proven in every area, and leave approvals work again","summary":"Every product area now has tests against a real database proving that one workspace cannot read or change the records of another workspace. They found and closed several places where a workspace could link its own records to another workspace, and they found that approving or rejecting leave failed for every approver.","content_text":"# 1.185.0: Workspace boundaries, proven\n\n## Fixed\n\n- **Leave approvals.** Approving or rejecting a leave request failed for every approver. It now works, and records the approving employee.\n- **Links across workspaces.** A workspace could link its own new records to records in another workspace by id: a huddle on a private channel of another workspace, a form attached to a project of another workspace, a time entry booked against a task or project of another workspace, a capacity row for a person outside the workspace, and loans, leave, reviews, goals and job openings naming employees, departments or locations of another workspace. Each is now refused as not found. No record was ever readable across workspaces.\n- **Saved reports** are private to the person who saved them, as the list always showed: another member can no longer open, run, change or delete one by its id.\n- **Announcements** of another workspace answer as not found, so their ids are never confirmed.\n- **Timers.** Starting a timer while one runs in another workspace now explains what to do, instead of failing with an unexpected error.","date_published":"2026-09-29T00:00:00.000Z","tags":["breaking"]},{"id":"1.186.0","url":"https://atlas.wrxstack.com/changelog/release-1-186-0","title":"45 new webhook events, and CRM activities log again","summary":"Webhooks now cover time entries, project risks, CRM activities and lost deals, wiki publishing, meeting transcripts and notes, form submissions, booking pages, PDF documents, files, report deliveries, data exports, plan changes and invoices, and, by choice, chat, huddles, client delivery and connected accounts. Logging a CRM activity, which had stopped working, works again.","content_text":"# 1.186.0: More of Atlas reaches your webhooks\n\n## Added\n\n- **Work:** `task.moved`, `project.restored`, `project_risk.created` and `.updated`, `time_entry.created`, `.updated` and `.deleted`, `crm_activity.created`, `crm_account.merged`, `crm_deal.lost`, `wiki_page.published` and `.revision_restored`, `meeting_notes.generated`, `client_onboarding.completed`.\n- **Documents and the workspace:** `form_submission.created`, `booking_page.created` and `.updated`, `booking.no_show_marked`, `pdf_document.created` and `.finalized`, `report.delivered`, `data_export.completed`, `subscription_plan.changed`, `invoice.paid`.\n- **Sent only when a webhook names them:** `meeting_transcript.ready`, `attachment.created` and `.deleted`, `chat_message.created`, `.updated` and `.deleted`, `chat_channel.created` and `.archived`, `huddle.started` and `.ended`, `engagement.created`, `.updated`, `.transitioned` and `.closed`, `deliverable.submitted`, `.approved` and `.rejected`, `billing_milestone.reached`, `connector.connected`, `.disconnected` and `.sync_failed`. A webhook subscribed to every event does not receive these; name the event or its resource. A chat message outside a public channel is sent without its text.\n\n## Fixed\n\n- **CRM activities.** Logging a call, email or meeting against an account, contact or deal failed every time, in the app and through the API and MCP. It works again, and a logged call or meeting keeps its duration.\n- **Events fire once, on a real change.** An edit that changes nothing, a repeated stop, end or disconnect, or a retried request no longer sends a second event.","date_published":"2026-09-29T00:00:00.000Z","tags":["feature"]},{"id":"1.169.0","url":"https://atlas.wrxstack.com/changelog/release-1-169-0","title":"Access tokens: one set of rules across the whole API, and control over sensitive areas","summary":"Personal access tokens and OAuth access tokens now follow one set of rules on every part of the Atlas API. A token acts as the person who created it, reaches an operation only when that operation declares a scope the token holds, and cannot reach client delivery, connected apps, service operations, or chat content until a workspace administrator allows it.","content_text":"# 1.169.0: Access tokens\n\n## What changed\n\n- **One rule everywhere.** An operation accepts a token only when it declares the scope it requires, and only when the token holds that scope. An operation that declares no scope refuses tokens with the problem type `scope-not-declared`.\n- **A token is its owner.** A token is subject to its owner's role, module permissions, and plan, exactly as when they are signed in. Scopes only narrow it. When the owner is removed or disabled, or the workspace is archived, every token they created stops working on the next request.\n- **Sensitive areas.** Tokens cannot use the `delivery`, `connectors`, `service`, or `chat` scopes until a workspace owner or administrator allows that area in Settings, then API access, under Sensitive areas. A refused call returns `scope-family-disabled`. Allowing or withdrawing an area applies at once and is recorded in the audit log.\n- **Every product area is available to tokens.** About 2,500 operations across tasks, projects, CRM, contracts, eSign, booking, meetings, the wiki, HR, payroll, client delivery, client onboarding, service operations, reports, dashboards, connectors, workspace administration, and privacy now accept a token that holds their scope, with new scopes for each area. Operations that act on your own records, such as your profile or your leave requests, are included.\n- **The OpenAPI document lists every one of them.** `/v1/openapi.json` grows from 529 to more than 2,400 operations, each with its required scope and the request schema the API enforces, and it lists nothing a token cannot call. The Postman collection follows it.\n- **MCP tools reach the API.** Most MCP tools pointed at operations that refused the token the MCP server sends. More than 1,500 of them now work.\n\n## Changes to existing behaviour\n\n- **Creating or rotating a token now requires signing in.** `POST /v1/pats` and `POST /v1/pats/{id}/rotate` refuse a token with `session-only`. Listing and revoking tokens still work with `pats:manage`, so an automated system can revoke a token that has leaked.\n- **Tokens cannot be created while acting as someone else.** A super administrator who is impersonating a person is refused with `impersonation-forbidden`, so no token outlives an impersonation.\n- **The workspace IP allowlist applies to tokens.** It used to apply only to signed-in sessions. A token's own allowlist still applies as well.\n- **Calls through the hosted MCP server** are checked against the address of the person using it, not the address of the server.\n- **A token may carry every scope.** The limit of 32 scopes per token is gone.\n\n## Fixed\n\n- **Inbound script automation webhooks.** An outside system calling a script automation webhook with its secret was refused before the secret was checked. It is now accepted.","date_published":"2026-09-28T00:00:00.000Z","tags":["breaking"]},{"id":"1.168.0","url":"https://atlas.wrxstack.com/changelog/release-1-168-0","title":"Chat: real-time messaging, built into your workspace","summary":"Chat brings channels, direct messages, and threads into Atlas, right next to the work. Messages arrive the instant they are sent, you can react, mention people, attach files, pin what matters, and search everything you can see, and the connection heals itself when your network drops.","content_text":"# 1.168.0: Chat\n\n## Where to find it\n\n- **Chat**: the sidebar, or Cmd-K and type \"chat\".\n- **A new message**: the New message button at the top of the channel rail.\n\n## What you can do\n\n- **Channels** for a topic, a team, or a project. A channel can be public, so anyone in your workspace can find and join it, or private, so only an invited list can see it.\n- **Direct messages** for one person or a small group. They are visible only to the people in them.\n- **Threads** that keep a focused reply chain out of the main conversation.\n- **Reactions, mentions, and read receipts.** React with an emoji, type @ to mention a teammate, and see who has caught up.\n- **Attachments.** Drag a file or image onto a conversation and it previews inline. Every attachment is scanned before it is shared, and a file that fails the scan is quarantined and never delivered.\n- **Pins and saved items** for anything worth keeping.\n- **Search** across every channel and message you have access to, and never across ones you do not.\n\n## It heals itself when your network drops\n\nWhen your connection wobbles, Chat notices right away and shows a reconnecting indicator, so you are never left guessing. Whatever you were reading stays on screen. When the connection comes back, Chat quietly fills in the messages you missed so you do not have to refresh, and a message you sent stays queued and is delivered as soon as you are back online.\n\n## Your privacy, and your admin controls\n\nYou only ever see channels and direct messages you are a member of. A private channel is completely hidden from everyone who has not been added, and no one, including a workspace admin browsing the app, can read a conversation they are not part of. Your admin can set a retention window and a legal hold, and under a legal hold messages are preserved even when a retention window would otherwise remove them. Editing or deleting a message keeps an audit trail.","date_published":"2026-07-16T00:00:00.000Z","tags":["feature"]},{"id":"1.165.0","url":"https://atlas.wrxstack.com/changelog/release-1-165-0","title":"A better greeting, and calendars from around the world","summary":"The dashboard greeting is warmer and no longer has stray keyboard chips stuck to your name. The world calendars strip now actually appears, and supports 18 calendar systems.","content_text":"# 1.165.0: Greeting and calendars\n\n## The greeting\n\nThe dashboard used to greet you and then weld two keyboard-shortcut chips to the end of your name, advertising a shortcut to the screen you were already on. That is gone.\n\nThe greeting itself is now worth reading: seven times of day, several phrasings each, and an emoji that matches the hour. It is stable while you work (it will not flicker between renders) and it changes tomorrow.\n\n## World calendars\n\nThe calendars strip was in the product, but it rendered nothing unless you had already been into Settings and turned a second calendar on. Since almost nobody had, almost nobody knew it existed. It now always appears, and you can pick your calendars from the strip itself.\n\n**18 calendar systems** are supported: Gregorian, ISO-8601, Islamic (including Umm al-Qura, Civil and Tabular), Hebrew, Persian, Indian, Buddhist, Chinese, Dangi, Japanese, Minguo, Coptic, Ethiopic and Ethiopic Amete Alem. Pick the ones you use; they are remembered across your devices.\n\nOne correctness note: your browser does not report an error for a calendar it cannot render; it quietly gives you a Gregorian date instead. We now detect that, so a calendar you select either shows you a genuinely correct date or is not offered at all. A wrong date under a confident label is worse than no date.","date_published":"2026-07-13T00:00:00.000Z","tags":["feature"]},{"id":"1.166.0","url":"https://atlas.wrxstack.com/changelog/release-1-166-0","title":"Compliance controls, announcements, and a fix for the super-admin header","summary":"Legal holds, retention policies, IP allowlisting, SIEM export and SCIM group mapping now have real screens. The super-admin page header no longer covers the page when you scroll, and the storage usage dashboard works again.","content_text":"# 1.166.0: Admin and compliance\n\n## Compliance features that had no screen\n\nSeveral enterprise controls were fully built on the server and had no user interface at all, which means nobody could use them. They now have one:\n\n- **Data retention and legal holds.** Settings, Data retention.\n- **IP allowlist.** Settings, Security.\n- **SIEM audit export.** Settings, Security.\n- **SCIM group to role mapping.** Settings, Access.\n\n## Announcements\n\nYou can now **edit** an announcement after writing it, not only publish or delete it, and you can manage the **type catalog** rather than living with whatever was seeded at boot.\n\n## Fixes\n\n- **The super-admin header stayed pinned to the top of the screen.** Because it included the title and a multi-line description, it covered roughly 200 pixels of whatever you scrolled, so tenant lists and audit tables slid underneath it and became unreadable. Page titles are context, not controls: it now scrolls with the page. The filter bar, which is the thing you actually keep reaching for, is what stays pinned.\n- **Storage usage showed \"Could not load storage usage\".** The dashboard was asking the API for a path that did not exist, so it had been broken for every super admin since the day it shipped. Fixed, and a new guard now checks every client call against the routes the API really serves, so this class of bug cannot ship again.\n- **The public changelog editor** was reachable only if you already knew the URL. It is now in the super-admin navigation.","date_published":"2026-07-13T00:00:00.000Z","tags":["breaking"]},{"id":"1.167.0","url":"https://atlas.wrxstack.com/changelog/release-1-167-0","title":"PDF Studio: a real conversion engine, and a PDF editor you can actually reach","summary":"PDF conversion moves off the API and onto a dedicated worker, with real page-by-page progress, cancellation, a 100 MB limit, and results that auto-delete after 24 hours. The PDF editor, which was built but unreachable, now has an entry point.","content_text":"# 1.167.0: PDF Studio\n\n## Where to find it\n\n- **PDF Studio**: the sidebar, or Cmd-K and type \"PDF\".\n- **Edit PDF**: PDF Studio, in the Edit group. It was previously built but had no way in: no tile, no link, and no way to create a document. Now you drop a PDF on it and start editing, with every save kept as a version you can restore.\n- **Recent jobs**: from any conversion tool, so you can pick a result back up.\n\n## What changed under the hood, and why you will feel it\n\nConversions used to run inside the web request, in the same process that answers every other API call. A large document therefore held a connection open for minutes and competed for CPU with everybody else on the platform. One tenant converting a 2000-page PDF could slow the product down for everyone.\n\nConversions now run on a dedicated worker:\n\n- **Your browser uploads straight to storage.** The file no longer travels through the API, so the old 50 MB ceiling is gone. The limit is now **100 MB**.\n- **Real progress.** Not a spinner. You see the stage, the page it is on (\"Converting page 14 of 24\"), a percentage, and a time estimate. Where we cannot know the exact page (LibreOffice reports nothing while it works) we say so honestly rather than inventing a number.\n- **Cancel actually cancels.** Rendering is chunked, so there is a real point at which we can stop.\n- **Close the tab.** The job keeps running and the result is waiting in Recent jobs.\n- **One workspace cannot starve another.** A tenant can hold at most a fixed number of worker slots no matter how many jobs it queues.\n\n## Your files are deleted\n\nBoth your upload and your result are permanently removed from our storage **24 hours** after a job finishes. You will see the countdown on the result. If you want to keep something, press **Keep permanently**; if you want it gone now, press **Delete now**. Every one of those actions is written to the audit log.\n\n## Honest output\n\nIf we degrade your result, we tell you: a document truncated at the page cap, pages rendered at a lower resolution to fit the memory budget, or a scan with no text layer (where a PDF-to-Word conversion would otherwise hand you pictures of text and no explanation).","date_published":"2026-07-13T00:00:00.000Z","tags":["fix"]}]}