With Elevation Request Ticket Settings enabled and every required field mapped, raising a manual End-User Elevation request didn't result in a ticket being created in Datto Autotask. The configuration saved fine and the elevation request itself worked normally, so there was nothing in the dashboard to indicate ticket creation had failed — the missing ticket in Autotask was the only symptom.

The cause related to the fields Autotask requires when creating a ticket. Elevation request tickets are now created in Autotask as expected, so elevation activity reaches your PSA and technicians can work requests from there.

If you'd turned elevation ticketing off because tickets weren't appearing, it's worth enabling and reviewing your configuration again. The elevation requests themselves were always processed correctly — only the resulting ticket was missing.

When a rule inside an elevation policy was added, removed or modified, the resulting event recorded only the number of rules the policy ended up with. Two different changes could produce identical-looking events, so the log told you a policy had been edited but not what the edit was.

Events now describe the change itself:

Changes that loosen or tighten an elevation rule are now traceable after the fact, and a deleted rule leaves a record of what it contained rather than having to be reconstructed from memory.

Events recorded before this release keep their original level of detail.

The Technician Users list now has a column, between Login Role and Status, showing which Technician Groups each technician belongs to. Previously the only way to find this out was to open each Technician Group in turn and look at its assigned users.

Where a technician belongs to more groups than the column displays, a indicator shows how many more there are, and hovering over the column reveals the full list. The column can be resized like the others.

Technicians with the Super or Primary login role can't be assigned to a Technician Group, so their rows show the usual empty placeholder.

Handy when reviewing access, since Technician Group membership determines which customers a technician can work with and which alerts they receive.

When approving a one-time elevation request, the note on the screen said the end user could enter elevated mode once within — twice the window that actually applies.

The message now correctly states , matching the period in which an approved one-time elevation can be used.

If you'd previously told an end user they had 48 hours based on this message, the real window was shorter — an elevation left unused beyond 24 hours would have needed a new request. This was a wording correction only; the elevation window itself hasn't changed.

Moving a customer from one automatic import policy to another used to mean editing the policies themselves — removing the customer from one, then finding and editing another to add them. A new button on the customer's screen now does it in one step.

The button reads when a policy is already assigned, or when none is. Selecting it opens a dialog listing only the policies that apply to the section you're in — End User Import Options, End User Import Source, Administrator Import Options, or Administrator Import Source — sorted alphabetically, with the current policy pre-selected. Hovering over a policy shows which options it has enabled, so you can check what it does before switching a customer onto it.

Confirming updates everything at once: the customer is removed from the old policy's customer list, added to the new one, and the policy name and link on the screen update.

If a switch would change the import source, you're warned before committing, with a pointer to the password sync option if you need both Active Directory and Microsoft 365. You can't switch to a Microsoft 365 policy while password sync is enabled, or enable password sync while on a Microsoft 365 policy. The buttons are unavailable while an import is running, so a change can't land mid-import.

If the import source was disabled, assigning or switching a policy runs the import immediately and re-enables it.

Each one creates an event showing the policies involved, the customer, the account type and the technician who made the change — filterable and exportable like any other event.

The buttons appear only for roles with permission to create and manage policies.

Please reach out to Support support@cyberqp.ai to enable this feature during the phased roll out stage.

On Password Vault tenants, every row in the Password Rotations report showed a QP Status of , whatever the underlying rotation status actually was. Because the column returned the same value for every entry, it said nothing about the state of your rotations and couldn't be used to spot entries that needed attention.

The QP Status column now reflects the actual status of each password rotation, so the report shows the real state of rotations across the tenant. If you'd previously discounted this report because every row looked unmatched, it's worth another look.

This affected how the status was reported only — rotations themselves ran as configured.

Extending the timer on an active JIT account now does what you'd expect across every account source.

For Active Directory and Entra ID / Microsoft 365 accounts, the countdown to automatic expiry previously carried on unchanged, so the account was disabled at its original time regardless of the extension. Extending now adds the selected period to the time remaining, and the dashboard shows the new expiry — a one-hour JIT account extended by an hour after 35 minutes will show 1 hour 25 minutes remaining.

Extending also regenerated the password on Active Directory and Local accounts, so a technician already signed in with that credential found it no longer worked — the opposite of what extending a session is for. The existing password is now left in place across all sources.

This applies consistently to Active Directory, Local and Entra ID / Microsoft 365 sources, to both standard and burner JIT accounts, and whether you extend from the dashboard, the browser extension or the QTech mobile app. Events recorded for an extension show the correct updated expiry time.

Password Edited audit events used to show only each field had changed — a YES or NO against it. They now record what actually changed.

for Display Name, Username, Account Type, Computer Name, URL, Notes and Password Access. Previously a change to Password Access recorded only what it had been changed , so there was no way to tell from the audit trail what access had been in force beforehand. The YES/NO indicators remain, with the detail beneath them.

— the event states whether a passcode was created, changed or deleted, so a second factor being removed from an account is visible in the audit trail rather than looking like any other edit.

Password and passcode values are not written to events; for these fields the event says only that a change occurred — the password was changed, the secret key was removed — never the value before or after.

Edits to an account linked to a source open with , and entries in Other Passwords with , with the Source column showing the account name.

Events recorded before this release keep their original level of detail.

Triggering for a customer records an event for each source that was synchronised. The Active Directory event reported success but named the AD rather than the AD — the domain controller the sync had actually run against. Because it named a machine that wasn't the sync target, it looked as though the sync had only reached the member server.

The Active Directory entry now identifies the server the sync actually ran against, so the event log accurately reflects which systems were synchronised.

This was a reporting issue only — the synchronisation itself ran correctly against the intended servers; only the server named in the event was wrong.

Moving an account from Administrator Accounts to End User Accounts wasn't recorded as a manual import. The auto-import engine then evaluated the moved account against the End User import criteria and, if it didn't meet them, removed it — after which it became eligible for automatic import again and could be pulled back into Administrator Accounts.

On tenants with Administrator Account auto-import configured with documentation platform matching (IT Glue, Hudu or Vault) and rotation enablement, the re-imported account could then be matched and have password rotation enabled. So a deliberate correction could be undone: an end user's account mistakenly imported as an administrator account, moved across to put it right, could end up back where it started with its password rotated — and a standard end user has access to neither the documentation platform nor the dashboard to retrieve it.

Moving an account between the two menus now flags it as a manual import, and the auto-import engine leaves it alone. Your move is preserved rather than reversed on the next import run.

If you previously moved an account and later found it back in Administrator Accounts, move it again — it will stay put now. If its password was rotated in the meantime, the current password is in the matched documentation entry or the CyberQP vault.