August was a month about joining things up and drawing lines. Support conversations became whole, so a requester’s email reply now appears in the ticket thread instead of sitting in a linked email somewhere else, and tickets waiting on your team stand out on the board. Account control got real teeth, with administrators you can appoint and ownership you can transfer. A connected AI assistant can now build a complete, linked set of QA records on its own. And we shipped our longest security list yet, including the subscription requirement and a set of platform limits. Here’s the full rundown.
Ticket Conversations and Board Visibility
Email replies from requesters now appear directly in the ticket conversation. A new Add Email to Conversation workflow action appends an inbound reply to the thread of the ticket it belongs to, so you read what was said in order alongside your own replies rather than opening a linked email to find it. Add the action to an email workflow after Extract Ticket References, and it needs no configuration of its own.
Each entry is attributed to the person who sent it, so the thread shows their name rather than System, and a contact is created automatically the first time an unknown address writes in. Processing the same email twice never duplicates an entry. An inbound reply does not satisfy the first response target on your SLA, because a requester writing in is not an agent responding, and it does not change the ticket’s status. Reply handling stays yours to define through workflows.
Tickets waiting on your team now stand out on the Kanban board. When a requester replies, the card is marked with an accent and a Requester replied badge showing how long the reply has been waiting, so a two hour wait looks different from a two day one. Those cards float to the top of their lane, which makes a pending response hard to miss when scanning the board, and your chosen sort still applies within each group so floating never overrides how you have ordered a lane.
A new Awaiting Reply filter narrows the board to what is waiting on your team or on the requester, and a Last Reply sort orders tickets by most recent conversation activity. Both are available on the ticket list and its exports too. Internal notes do not count as answering the requester, so adding a note leaves a ticket marked as still awaiting a reply, while replies sent by automation such as a canned response from a workflow do count. Existing tickets were included, so the board reflects real conversation state straight away.
Formatting Carried Across the Help Desk
Creating a ticket from an email now carries the email’s formatting across. Headings, lists, bold text, links, and images previously arrived as flat text. Creating an issue from a ticket keeps the ticket description’s formatting in the same way. Both description fields are now full rich text editors, with the toolbar, tables, the media library, image upload by drag and drop or paste, and AI assist, and both dialogs are wider so the toolbar fits comfortably. Nothing changes for existing tickets or issues.
Administrators and Account Ownership
Owners and administrators can now grant and revoke the Admin role from the role dialog on Account Users, which previously locked every system role. The Basic role stays fixed, because every member holds it automatically. An account always keeps an administrator, so removing the Admin role from the last remaining administrator is refused. You may give up your own while another administrator remains, and you are warned first that you will not be able to restore it yourself.
The account owner can transfer ownership to another member from Account Users, confirming their identity first. The new owner also receives the Admin role, and only they can transfer it back. An account can no longer be left without an owner either: a user who owns one cannot be deleted or unlinked from it until ownership has been transferred to somebody else. When an account owner deletes their account and no other members remain, the account is now deactivated and any outstanding invitations are withdrawn, rather than being left active and empty.
Removing someone’s role now narrows every API and MCP token they created straight away, because token permissions are checked against what the holder currently holds rather than what they held when the token was made.
A Full Set of QA Records Over MCP
A connected AI assistant can now build a complete set of QA records on its own. Previously it could create a test case but not give it any steps, create a user story but not attach acceptance criteria, and create a test cycle but not put anything in it, so every record made this way had to be finished by hand in the console.
Test steps can now be listed, added, edited, reordered, duplicated, and deleted, and a test case can be created with all of its steps in a single request. Acceptance criteria can be supplied when a user story is created or updated, and each criterion comes back with its own identifier and its coverage, so an assistant can link a test and then confirm the link took effect. Tests can be linked to a user story or to one individual acceptance criterion, in both directions. Linking at the criterion rather than the story is what makes partial coverage visible in the traceability matrix, and it is the practice we recommend.
Cycles can now be populated. Adding test cases creates the test runs, a cycle can be cloned, and its progress can be read back. Each run accepts an environment and a priority, Pass, Fail, and Blocked results for every step, comments, and links to any defects it uncovered. Adding test cases to a cycle takes an optional environment that is applied to every test run it creates, and this works the same way through the API as it does over MCP, so a cycle no longer has to be set up one run at a time.
Test case folders and test cycle folders can now be read as a tree, created, renamed, moved, and deleted, so records created this way can be filed rather than piling up unfiled. Deleting a folder that still holds records or subfolders is refused unless you explicitly ask for it, and when you do the records move to the top level instead of being deleted along with it.
AI Reformat
A new Reformat action in the Refine tab of the AI writing assistant tidies how your content is laid out without changing a single word of it. It splits a wall of text into paragraphs, turns a run of items into a proper list, promotes lines that read as section titles into headings, and cleans up stray formatting. Every other refine action changes your words, whether shortening, expanding, or adjusting the tone, so Reformat is the one to reach for after pasting content in from somewhere else. It is available wherever the AI Assist panel appears, in English, Spanish, and German.
Who Created What
Notes, tasks, and contacts now record who created them. The notes and contacts lists show a Created By column, and the CSV export for all three includes it. A new Created by filter on those three lists narrows them to one person’s records, with a System option for anything created by a workflow, the scheduler, or from an inbound email rather than by a member of your team. Notes also gained bulk delete, so selecting several and removing them is a single action where before each note was deleted one at a time.
Records created before this release show System as their creator, because the creator was not recorded at the time. Nothing about those records is changed, and no action is needed from anyone.
The Subscription Requirement
Working in an organization now requires an active subscription. When a free trial runs out, or a cancelled subscription reaches the end of its paid period, requests for that organization’s records are refused until it is subscribed again. Until now an expired trial kept full access indefinitely.
Nothing is deleted when that happens. Your issues, tests, documents, and history stay exactly as they were and are all there again the moment you subscribe. What you need in order to resolve it, or to leave, stays open: signing in, the billing pages and your invoice history, switching to another organization you belong to, viewing and accepting invitations, your own profile and security settings, a full data export, and deleting the account. So nobody is ever locked out of the one page that brings the organization back, and no organization is held hostage to get its data out. Other organizations you belong to are untouched, because the block applies to an organization and never to your user.
A failed payment that Stripe is still retrying does not lock anybody out. Your organization keeps working normally throughout the grace period, which is the window to update the card, and only an exhausted retry sequence ends access. API tokens and MCP clients follow the same rule with one refinement: they can still list the tools available to them and read records, but anything that would create, update, or delete is refused with a payment required response. An integration therefore reports the reason plainly rather than appearing to break, and starts writing again as soon as the subscription is active, with no change needed on its side.
Platform Limits
Several parts of the platform had no ceiling on how much of them one account could accumulate. That is now bounded, and the limits sit well above anything a real team does.
- Account users: there is now a ceiling on how many users an account can hold, counting invitations that have been sent but not yet answered. Accounts with an active subscription are held to a high limit that no real team reaches, because every user added is already billed for. Accounts without one are held to a much lower limit, and subscribing lifts it straight away with nothing to ask for. An account already above its limit keeps every member and all of its data, and is only prevented from adding more.
- Invitations: account invitations are now rate limited, per administrator and per account, covering both sending a new invitation and resending an existing one. This closes off a way the invitation system could have been used to send large volumes of unwanted email. Inviting people at a normal pace is unaffected.
- Organizations: the number of organizations one person can create is now limited, and creating them is rate limited too. Without this the user ceiling could have been sidestepped by starting another organization rather than filling the current one.
- API tokens: the number of active API tokens an account can hold is now limited, and MCP request limits now apply per account as well as per token. Previously each token carried its own separate allowance, so holding more tokens raised the total an account could send. Revoke a token you no longer use to make room for a new one.
- Request rates: every part of the API now sits behind an overall limit on requests per minute, applied per signed-in user rather than per location, so nobody’s activity can crowd out a colleague’s. Requests that create, edit, or delete carry their own limits on top of that, per user and per account, because the overall limit was sized for the volume of reading the console does. Reading is unaffected, the admin console and mobile app never approach either limit, and inbound webhooks from Stripe, Google Calendar, and your own integrations are untouched.
- Calendars: there is now a ceiling on the number of personal calendars you can hold in an organization, and a limit on how quickly calendars and events can be created. Your account calendar and any calendars you connect from Google do not count towards the ceiling. Previously a single account could accumulate enough calendars to make its own calendar sidebar slow to load.
Data Retention Policy
A Data Retention and Disposal Policy is now available in Compliance, setting a seven year baseline for business records, with shorter periods where a shorter period is justified.
Improvements and Fixes
- Bulk actions: where an action has to be applied to each record in turn, it no longer stops at the first problem and reports one generic failure. It continues through the rest of the selection and tells you how many records were processed, and if it stopped because a limit was reached it says how many are left so you can run it again for the remainder. Bulk delete on features and user stories is now a single request rather than one per record, which makes it noticeably quicker on a large selection.
- Unverified email: if the verification email never arrived, or its link expired, signing in with your email and password now takes you to a page offering to send a new one, with your address already filled in, instead of leaving you on the login screen with nothing to act on. A new link can be requested once a minute and up to three times an hour. Note that resetting your password does not lift the block, so use the resend rather than Forgot password?
- Kanban board: fixed tickets disappearing from the board. It was only ever loading the ten most recent tickets and spreading them across all six lanes, so cards seemed to vanish at random whenever a ticket was created or the sort changed. The board now loads its full set, and the page size selector on the ticket list works instead of always returning ten rows. Tickets show thirty per page by default.
- Notes search: fixed notes dropping out of search after an automation updated them. A workflow that changed a note’s content did not refresh the text used for searching and for CSV and PDF exports, so a note could stop matching a search for words it plainly contained. Affected notes are corrected on upgrade.
- Sign-up form: the Full Name and Company Name fields now stop at 255 characters and tell you when you have reached the limit, instead of accepting a long value and then failing with a generic error on submit. The same limit applies when you sign up from the mobile app.
- Add User dialog: it now shows how much of your account’s user allowance is in use, and when the allowance is reached it says so and explains what to do about it, rather than accepting the form and refusing it on submit.
- Google sign-up: fixed being signed out when setting your first password after signing up with Google. Returning from Google ended the session that had just been created and left you back at the sign-in screen. Accounts created by signing up with Google now receive exactly the same session as any other sign-in.
- Google account linking: fixed linking a Google account from Security Settings, which signed you in again instead of linking anything. Choosing Link Google account now takes you to Google, asks which account you want to attach rather than assuming the one you are already signed in to, and reports the outcome when you return.
- MCP test cycles: fixed the test cycle tool accepting three settings and then quietly ignoring them. An environment, a planned start date, and a planned end date were all accepted, the response reported success, and none of the three was stored, so a cycle looked correctly set up when it was not. A misnamed setting is now refused with the list of the ones that are accepted. The same fault was fixed in the test environment tool, which advertised a browser, an operating system, and a device, none of which exist.
Security
August was our largest security month so far. Alongside routine updates across the frameworks and third-party components behind ISO Mate, here is what changed.
- Account separation in role management: fixed a privilege escalation. Permissions on account level requests were checked against the account you had marked as active rather than the account the request actually addressed, so someone who belonged to more than one organization could use one of them to gain administrative access to another, including granting themselves its Admin role. Permissions are now always evaluated against the account named in the request, and you must be a member of that account. Reported to us externally with a clear, reproducible proof of concept.
- Custom object types: one part of the custom objects area took the account to work with from the request instead of from your signed-in session, so a signed-in user could have read the field definitions of another account’s custom object types, or added a new object type into another account. Every part of that area now uses your own account, taken from your session, and ignores anything sent in the request. No entry data was reachable this way. Reported to us externally with a clear, reproducible proof of concept.
- No escalating your own authority: assigning a role, creating a role, or adding permissions to an existing role is now refused when it would grant a permission you do not have in that account. Renaming or trimming a role that is broader than your own access still works. Requests aimed at a disabled account are now rejected even when your own active account is healthy.
- Dashboard figures: fixed dashboard figures being readable without the permission for the module they came from. Which panels appeared was decided in the browser alone, so the figures behind a panel could still be read by a member with no access to that part of the product. Every panel is now checked on the server against the same permission that governs the module itself. A member who can reach some modules but not others still gets a working dashboard, showing the parts they are entitled to. Reported to us externally with a clear, reproducible proof of concept.
- Uploaded files: only images and PDFs are now displayed inline. Every other file type is delivered as a download, and file types a browser can execute as a page or a script, such as HTML and JavaScript, are no longer accepted as attachments. This closes a stored cross-site scripting risk and prevents attacker controlled pages being hosted on an ISO Mate address for phishing. The same protection applies everywhere ISO Mate serves an uploaded file, including files uploaded before the change, because the restriction is applied at the moment a file is served. If you need to share a web page or a script, add it inside a zip archive. Reported through our vulnerability disclosure program.
- Credentials in file links: file and image links no longer carry your access token. Previously, opening an attachment preview or displaying your account logo placed a credential in the address, where it could be kept in browser history and server logs. The admin console and the mobile app now request the file over an authenticated connection instead, and the ability to sign in through a link has been removed from the API altogether.
- Email verification: fixed a bypass when signing in with Google, which granted full access to an account whose email address had never been confirmed. Because Google confirms the address before passing it to us, a matching address now counts as proof that the address is yours. An account that has not confirmed its email address can no longer reach any part of the API either, so verification is now checked on every request rather than only at sign-in. Signing out and checking your own sign-in status still work, so an unconfirmed account is never left stranded. Reported through our vulnerability disclosure program.
- Google identity binding: signing in with Google is now tied to the specific Google account linked to your profile. If a different Google account is used, sign-in is refused, even when its address matches the address on your ISO Mate account. Previously two separate Google identities could reach the same account while only one of them was recorded as linked. Replacing the linked account now requires unlinking the current one first, which asks for either your password or a confirmation sent to your email address, and attaching a Google account now happens only inside your own signed-in session. Reported through our vulnerability disclosure program.
- Email changes and Google: changing your email address now unlinks a Google account that was linked to the address you are leaving behind, and signs you out of your other sessions. That link used to survive the change. It matters most when a work address is reassigned to somebody else after you leave an organization, because the new holder of that address could otherwise still sign in to your ISO Mate account. You keep access with your password, and can link Google again at any time.
- Sign-out: signing out now revokes your session even when a client sends nothing but its short-lived access token. Sign-out already worked correctly from the admin console and the mobile app, but a client that sent only the access token was told the sign-out had succeeded while the session actually stayed live for the remainder of that token’s fifteen minute life. That path now revokes every token in the session and records the sign-out in your account’s audit trail. Reported through our vulnerability disclosure program.
- Window isolation: the console now checks for itself, on the sign-in and registration pages, refusing to start the Google sign-in flow when it has been opened by a page from another site. The API sends the same isolation instruction as the console, and our website now sends it too, so all three agree. The protection no longer rests on a single piece of infrastructure. Every link the console opens to an outside destination is also opened in a way that leaves the new tab with no reference back to the ISO Mate tab that opened it. Prompted by reports through our vulnerability disclosure program.
- Browser caching: responses from the API are no longer written to the browser’s own cache. They were already kept out of shared and proxy caches, but a browser could still keep a copy on disk, so records carrying personal details could persist on a device after the session ended. Every API response now says not to store it, while deliberate caching of downloads, exports, and the public requester portal is left alone. The console also re-checks that you are still signed in when the browser restores a page from its back-forward cache.
- Inbound email encryption: inbound email to isomate.io now declares that encryption is required. A published MTA-STS policy tells a sending server which mail hosts are legitimate and that the connection must be encrypted, so a sender cannot be tricked into delivering a message unencrypted or to a substituted host. TLS reporting is published alongside it. The policy starts in testing mode, which reports problems without affecting delivery, and moves to enforcement once the reports confirm it is correct. Protections for mail we send were already in place, and this is the inbound counterpart. Reported through our vulnerability disclosure program.
- Token scopes: the Admin and Basic role definitions are now read only through the API, matching the restriction that already applied in the console, while assigning those roles to a user is a separate action and is allowed. Billing management can no longer be attached to an API or MCP token. It was already hidden from the scope picker, and it is now also refused when a token is created.
- Dependencies: third-party components across the API and the admin console have been brought up to their current patched releases, clearing every advisory raised by our automated dependency scans. The console’s runtime packages had been fixed to exact versions, which is why they could not pick up security patches on their own, so they now track patch releases and unused server-side rendering packages have been removed rather than carried along and rescanned each month.
What’s Next
There is more on the way across the platform. If you haven’t tried ISO Mate yet, sign up for a free 14-day trial at isomate.io. No credit card required, full access to everything from day one.
Got feedback? Reach out at support@isomate.io or use the built-in feedback portal inside the platform. Your input shapes what we build next.