Last updated 2026-08-19 · TALON v1.0-beta — rebuilt interface
What’s new in v1.0-beta
The interface has been rebuilt — same data, new map
A new left nav — eight groups, each screen carrying its reports on tabs. All 67 screens have been rebuilt against the same live API; nothing behind the interface changed.
No help articles match that search. Try a screen name — “crash”, “connector”, “chargeback” — or open a support ticket.
Articles
Article Library
Every link in the help grid above lands here. Use the browser’s find (⌘F / Ctrl-F) to jump to a topic, or scroll through by section.
Getting Started
What TALON is
TALON — Telemetry-Aware Logic & Orchestration Node — is RavenTek's multi-tenant MSP management platform. It reads device-experience telemetry from Riverbed Aternity and turns it into the questions an MSP actually asks: which accounts got worse this week, which devices are dragging, what is about to expire, and what can be fixed automatically — across every customer, from one login.
Every figure on every screen is read live through a single Aternity Connector. TALON does not hold a second copy of your telemetry, and it does not write changes back to Aternity except through the explicit remediation actions you run yourself. Settings that change how TALON behaves — alert thresholds, segmentation rules, EOL reference dates, AI provider keys — are stored on your instance.
All personally identifiable data is SHA-256 hashed before it leaves the customer environment for an AI provider. See PII sanitization.
The interface is organised into eight groups down the left side. Each entry opens a screen, and most screens carry a row of tabs across the top — the tabs are where the individual reports live.
Software — Inventory (Installed, Unused, Rationalize) and Licenses (Seats, End of life)
Optimize — Cost (Spend, Chargeback, M&A) and Sustainability
Automate — Actions (Library, Signing) and Query
Usage — Usage (Dashboards, Sign-ins, Changes)
Admin — Connector and Segments
Everything else — users, SSO, platform settings, the audit log and reference pages — sits behind the gear icon in the header, which has its own tabs: Users, Access, Platform, Audit and Reference.
Coming from the older interface? The screens are the same reports with shorter names. Account View is now Portfolio, Current Alerts sits under Signals, the MSP modules are split across Optimize and Segments, and Remediations moved to Actions.
The home screen — Portfolio → Quick links — opens with a single search box under Find a screen. It searches screen names, section names and URLs, so typing “crash”, “wifi” or “dh” lands you on the right screen in a couple of keystrokes. Press Enter to go straight to the first result.
Below the box, the quick links are grouped the same way the nav is — Overview, Experience, Analysis and Settings — with a one-line description of what each screen answers. It is the fastest way to hand a new technician the map.
Two controls in the header set the context for every screen you open next: the CLIENT picker and the time window (7, 14, 21 or 30 days). They persist as you move around, so you pick the customer once and then navigate freely.
Leave the picker on All clients for portfolio-wide screens. A number of screens report on one client at a time and will say so plainly rather than showing a partial figure — see “Select a client” on a screen.
Some screens carry their own period control that overrides the header for that screen only — Crash Impact has 7d / 14d / 30d buttons, and Top / Worst Explorer has its own period dropdown.
Jump to… in the header, or ⌘K / Ctrl-K, opens a command palette over whatever you are looking at. Type part of a screen name and press Enter. ⌘J / Ctrl-J jumps focus to the client picker instead.
The back and forward arrows next to the wordmark move through TALON's own screen history, and Tab opens the current screen in a new browser tab — useful when you want a client's executive page pinned while you dig elsewhere.
The right side of the header carries the display controls. Comfortable toggles row density for the big tables, and Dark switches the theme. Both are per-browser preferences.
The ? button opens Help & Definitions inside the portal: a searchable glossary of the 42 measures TALON reports, each with a link to Riverbed's own documentation for the underlying metric. Any term shown with a dotted underline anywhere in the app opens the same definition in place. Use it when the question is “what does this number mean”; use this help centre when the question is “how do I do this”.
The Feedback button in the bottom-right corner of every screen records a report together with the page you were on and the browser you are using. Those land in Bug Reports & Enhancements.
You will be given the URL of your instance. If your organisation has single sign-on enabled, the sign-in page offers a Microsoft button — use it. The first successful sign-in provisions your account automatically with the instance's default role, provided your email domain is on the allow-list.
If SSO is not enabled for your instance, an administrator creates the account for you on the User Admin screen and sends you the credentials.
Your first stop after signing in should be the Aternity Connector — most screens have nothing to show until it is configured.
When your account signs in through single sign-on, TALON does not hold a password for you at all. Admin → Access → Change password and Security both say so explicitly: change your password, and set up or reset MFA, with your identity provider. TALON enforces whatever the provider enforces.
Accounts that sign in with a local password show a password badge on the User Admin screen, and a no 2FA badge where second-factor is not in force. An administrator can lock and unlock those accounts from the same screen.
If someone signs in through SSO from an allowed domain but the instance requires approval, their request lands on Admin → Users → Access Requests rather than creating an account. The requester appears under Waiting with the address they used and how they asked.
An administrator clicks Approve and create the account — which provisions the account in one step — or Deny. Approved and denied requests stay on their own tabs as a record.
Admin → Connector is where every figure in TALON comes from. Configure it once per instance. The header shows the live state — Connected, which cluster is being read, the account focus and when it was last saved.
Choose the sign-in method (OAuth client credentials is the production default) and enter the credentials for your Aternity REST service account. They are encrypted on the server and are never sent back to the page — a saved client secret shows as present, with a Replace it button, and cannot be read back by anyone including you.
Because every screen reads through this one connector, a bad save takes every screen down at once. Test before you leave the page.
The right half of the Connector screen decides what gets read. Clusters lists all 24 Aternity clusters, grouped into Americas (CA1, US2–US5), APAC (AU1, MY) and dedicated tenants. Tick the ones your service account can reach; most instances read exactly one.
Account focus narrows the read to a single Aternity account. Leave it empty to read every account on the selected clusters — which is what an MSP normally wants, since the client picker then does the narrowing per screen.
TALON supports two shapes of multi-tenancy. The common one is a single instance whose connector reads several Aternity clusters and every account on them; the client picker switches between customers, and per-person visibility is controlled with User Scope.
For customers who require hard data isolation, TALON runs as a separate instance per customer, each with its own connector, users, SSO configuration and audit trail. Talk to your RavenTek representative about which shape fits your contract.
One TALON instance, many Aternity clusters, many customers per cluster — all surfaced through one filter.
Screens do not invent numbers. If the connector cannot answer, the screen says it could not load rather than showing zeroes, and the Audit Log records the failed call. A screen showing genuine zeroes — 0 incidents, 0 driver mismatches — is reporting a real result.
Overview → Portfolio is the score board: every account you can reach, scored on the experience its people actually get, worst first. The subtitle tells you how many accounts were reachable and how many were scored.
Pick an account and the Detail panel below the table fills in with that account's full picture — the same content as the Client Executive View. The Quick links tab alongside is the home screen described in The home screen and screen search.
Experience — the account's DXI, 0–100, shown as a coloured chip.
Change — week-over-week movement of that score.
Trend — a sparkline of weekly samples, drawn on a fixed 0–100 axis on every row so rows are comparable at a glance.
Licence — active or expired, with days remaining underneath, so a renewal never sneaks up on you.
Sources — which telemetry source the row was built from.
Sort by any column. The footer restates the rules being applied — worst first, fixed trend axis, week-over-week changes — so a screenshot of the table is self-explanatory when you paste it into a ticket.
The Analyze button at the end of every Portfolio row opens the full picture for that account. From there, ← All accounts in the top right takes you back to the list.
Analyze also pins the account in the header client picker, so the screens you open next stay on that customer.
The Quick links tab on Portfolio is the landing page: a search box over every screen, then the screens an MSP opens daily — Current Alerts, Portfolio, DXI · UXI · ART · BOOT, VIP Monitoring, Query Builder, M&A Scorecard, Network Model, SaaS Platform Status and the Aternity Connector — each with a one-line description of the question it answers.
Overview → Executive puts one client on one screen: experience, health pressure, licensing and console activity. It is built to be opened in a QBR without anything being assembled the night before.
The screen respects the header client picker and time window. Every score carries its movement against the previous window, and every score links to the breakdown behind it.
DXI — Digital Experience Index, 0–100, a weighted average of five categories.
UXI — User Experience Index, on its own 1–5 scale.
ART — application response time, in seconds.
Boot — boot time, in seconds.
Each tile states the change and says plainly whether that is better or worse than the previous window — which matters for ART and Boot, where a smaller number is the good one. Under each tile, What is moving … opens the decomposition — see What is moving a score.
The Health events card counts critical, major and minor events for the window, together with seats deployed and a per seat, critical + major figure. That last number is the one to compare across accounts: raw event counts scale with fleet size, events per licensed seat do not.
Licensing shows seats in use against seats licensed with the utilisation percentage, agents reporting against agents installed, how many are disconnected, the next expiry date and the licence status.
Console activity covers the trailing 21 days: dashboard views, sign-ins and the last sign-in timestamp — a fast read on whether the customer is actually using what they are paying for. Entitlements shows the tier and any add-ons. Open signals repeats the incident and anomaly counts from Incidents.
Overview → Signals → Alerts lists accounts that moved the wrong way since the last scan, worst first. The badge on the Signals nav entry is the count of open alerts.
The distinction that makes the queue readable: an account alerts because it got worse, not because it is low. A steady-but-poor account does not generate a fresh alert every scan. DXI is shown alongside the change so a small drop on an already-poor account is not read as a small problem.
Thresholds for what counts as a warning, major or critical live on Alert Thresholds.
Severity — Critical, Major or Warning; the chips above the table filter by it and show the count of each.
Account — which customer moved.
What — the rule that fired, such as Health Major, Boot Increase, Dxi Low or License Expired.
Detail — the same thing in a sentence: “Boot time increased 8.47s week-over-week.”
Change and DXI — the movement, and the level it happened at.
Since — how long the alert has been open.
The search box filters on any of it. Alerts cannot be acknowledged from this screen yet; the footer says so rather than offering a button that does nothing.
Alerts are produced by a scan. The line under the heading records when the last one ran and how many accounts it covered. Run a scan in the top right runs one immediately across every account you can see.
Scans are audited like any other action — look for alerts.run entries in the Audit Log, which show who triggered the run and the run number.
Signals → Live for this account runs the alert rules against the account pinned in the header, right now, and shows the result without saving anything. It is the screen to open when you have just made a change and want to know whether the rules still fire.
Because it evaluates one account at a time, it asks you to pick a client in the header before it will report. The thresholds it uses are the ones on Alert Thresholds → My Live Alerts, which also drive your stored background run.
Signals → Incidents lists open Aternity incidents by account, with a count of incidents and of accounts affected. Zero here means zero open incidents, not a failed read.
The table exports like every other table in TALON.
Signals → Platform status answers “is Aternity itself having a bad day?” without leaving the portal. It lists scheduled maintenance with exact start and end times — SaaS upgrades and unplanned maintenance windows alike — and per-component operational status for the platform your figures come from.
Worth checking before you chase a figure that looks wrong: a maintenance window usually explains it.
Experience → Overview is one row per account with all four measures side by side, plus the weekly trend. The subtitle summarises the portfolio in one line: how many accounts are scored, the average DXI, how many are at risk and how many are on watch.
Sort by any column, search accounts by name, and export the table. Analyze on a row opens that account's full picture. The footer states the conventions in force — worst first, trend axis fixed 0–100 across every row, weekly samples, week-over-week changes.
Every headline score links to its own decomposition: What is moving DXI, … UXI, … ART and … Boot. The DXI view lists the five categories — Business Applications, Collaboration Tools, Devices, Productivity Tools and Other Applications — each with its current value and its weekly change.
That is what makes a score defensible in front of a client: “collaboration is up 19.4, other applications are down 15.9” is a conversation; “DXI is 68” is not. Each category continues down to the measures and applications behind it. ← Back to the account returns you to the executive view.
Ranks applications, locations, departments or device models by how they are performing. Choose what to group by, which measure to rank on — Experience (UXI), Response time, Boot time or Health events per device — the period, and whether you want the top or worst 10.
Ignore below sets a minimum sample size. Use it: averages over a handful of samples swing wildly, and the un-filtered “worst” list otherwise fills with things nobody uses. Note that Boot time and Health events per device always group by device model regardless of the group-by selection.
Experience → VIPs reports experience for the devices belonging to the people who cannot afford a bad day: how many VIP devices there are, how many are at risk, and how much of the fleet was scanned to find them.
Who counts as a VIP is decided by the VIP rules on Fleet Segmentation. If this screen shows zero VIP devices, no VIP rule has matched anything yet — start there.
Experience → Startup answers which OS image the fleet is running and which of those images start and stay up worst. The header line counts image builds, devices, how many are scored, and app crashes across them.
It reports on one client at a time — pick one in the header. Where an image build correlates with poor boot time or crash volume, that is a reason to look at the build, not the devices.
Experience → Stability ranks application crashes by the time they actually cost someone. The distinction the screen is built on: a crash that someone relaunched cost them time, and a crash that stayed closed did not. Only the first kind is worth a ticket.
The tiles give total crashes, how many cost someone time, the total relaunch time measured on the devices, and the typical cost per crash that someone had to recover from. The table breaks it down by device, application, model and operating system, with a Cost someone time column showing how many of that row's crashes were followed by a relaunch.
Its own 7d / 14d / 30d buttons override the header time window for this screen.
Blue screens and hard stops — which devices, which models, and why. Counts system crashes and devices affected for the window, then breaks them down by crash reason and by hardware model, with a daily trend table underneath.
A crash reason concentrated on one model is a driver or firmware problem, not a fleet problem. That is the pattern this screen exists to make obvious.
Experience → Resources lists what each application costs in CPU and memory on the devices running it, heaviest first. Useful when a fleet feels slow but nothing is crashing.
Reports on one client at a time — choose one in the header.
Experience → Network shows access-point signal and channel health across the fleet, built entirely from endpoint telemetry — no WLAN controller integration needed. Tiles give the number of access points seen, average signal, driver mismatches and devices connected.
The table lists each BSSID with its SSID, channel, location, average signal, average SNR, connected devices, connection hours and throughput. Driver mismatches is the number worth watching: it is the endpoint-side cause of “the WiFi is bad” that infrastructure dashboards cannot see, because the access point is genuinely fine.
Estimates how a response time would change on a different link, before anyone pays for one. Enter the kind of traffic (web page or database / thick client), the payload in KB, the round-trip time in milliseconds and the server processing time; the screen returns a stacked response-time breakdown by bandwidth tier, split into server, round trips and transmission.
Read the split, not just the total. When transmission is 8% of the wait, a bigger circuit will not help and you can prove it in one screen. When it is 92%, more bandwidth genuinely helps — provided the receive window is big enough to use it.
These are modelled numbers, not measurements. The model assumes one connection at a time, no packet loss, no queueing and no congestion beyond TCP slow start. It is reliable about the shape of an answer and optimistic about the absolute figures. Use it to decide what to measure.
Experience → Calls scores Microsoft Teams calls per audio device. The header line gives the number of audio devices seen, the average MOS out of 5, the total calls and how many were poor.
Each row is a headset or webcam with its call score, poor-call rate, calls, distinct people, packet loss, jitter and whether it was used on-site or off-site. Having the network symptoms next to the device is what lets you separate a headset problem from a WiFi one — and turn “Teams was bad” into “that microphone drops 11% of its calls”, which is a fixable ticket.
Assets → Devices → Fleet scores every device and ranks them worst first, so triage starts at the top of the list. The subtitle states the measure in use and how many devices of the total were scored.
Each row carries the device name, processor and memory, its experience score, and the causes sitting next to it: system crashes, app crashes and hard resets. The Good / Average / Poor / No DXI chips filter to the tail of the fleet in one click, and each chip shows its count.
Devices → Health is about event volume rather than score: how many devices there are, how many produced events, and the critical, major and minor counts for the window.
The Event volume chart plots events per day and calls out the peak day by name, which is usually the thread to pull. From there you can drill to the devices and event types behind the spike. The screen states the window it is using directly under the heading.
Devices → Hardware answers what the fleet is made of and how old it is: total devices, a breakdown by manufacturer, and a table of every model with its CPU and the number of devices carrying it.
This is the inventory half of a refresh conversation. The recommendation half is Smart Asset Refresh.
Devices → Refresh answers which devices to replace, cascade or retire, and in what order. The tiles count devices assessed, hard EOL devices, devices under spec, and donate candidates.
“Hard EOL” is a manufacturer end-of-support date; “under spec” is a device whose measured experience is being held back by its hardware rather than its software. A donate candidate is serviceable but no longer fit for the persona using it. Scoring weights are configurable on Alert Thresholds → Device Refresh.
The planning companion to Smart Asset Refresh: refresh timing by model across the fleet, so a replacement programme can be spread rather than landing all at once. Reports on one client at a time.
Export the table for the budget conversation — it is the same figures the client will be asked to approve.
Devices → Agents tracks the Unified Agent rollout: how many agents are reporting, how many distinct versions are still in the field, and how they are distributed across accounts.
A long tail of old versions is the usual explanation for measures that exist on some devices and not others. Fix the tail before you trust a fleet-wide comparison.
Software → Inventory → Installed is the continuous record of what has been installed, updated or removed across the fleet: total packages seen and total device-updates in the window.
Every row shows vendor, package name, the version now and the version before, and how many devices moved. Each column has a contains-filter, so “what changed on Tuesday” is a search rather than an investigation — and the same history backs incident timelines when you need to know what changed right before something broke.
Inventory → Unused measures software that is installed and paid for but not being used, from real activity rather than install records. The tiles give underused installs, total installs and distinct titles.
Per title you get installed, active, underused and zero-usage counts. That is the renewal lever: walking into a licensing renewal knowing exactly what the client actually uses changes the conversation. The money view of the same data is Software Cost Overview.
Inventory → Rationalize asks which applications earn their place and which are candidates to retire — overlapping tools, near-zero usage, and titles that survive only because nobody has looked.
Reports on one client at a time; pick one in the header.
Software → Licenses → Seats puts licensed seats against seats actually in use: in use, licensed, utilisation percentage and accounts covered, then a row per account with status, whether it has expired, days till expiry and the next expiration date.
Sort by days till expiry to see the renewal runway across the whole portfolio at once. Licence expiry also drives a Signals alert, so an expiry does not depend on someone opening this screen.
Admin (gear) → Reference → EOL Reference List holds the rules that decide which software is treated as end-of-life and from what date. Each rule names a vendor, a match string against the software name, and an end-of-life date — for example, names containing “java 6” from February 2013.
Rules ship seeded and can be edited, added to, or set to stop counting without deleting them — useful when a client has a supported extended-support contract for something the rest of the world considers dead. Every change is attributed and dated on the row, and lands in the Audit Log.
Optimize → Cost → Spend turns the unused-software picture into money: estimated potential savings, underused installs, total installs, and the number of products against the catalogue size.
The products table ranks the opportunities — per title: category, installed, active, underused, no usage, activity-only and estimated savings. The estimate is per product and clearly labelled as an estimate; the underlying install and usage counts are measured.
Cost → Chargeback reports what each group costs, monthly and annually. The groups are the business units and cost centres defined by the rules on Fleet Segmentation — if this screen looks empty or lumps everything together, the rules are what to fix.
Reports on one client at a time; pick one in the header.
Cost → M&A summarises estate condition at a glance for due diligence: an overall score, devices at risk, EOL devices and devices due for refresh.
It is the one-page answer to “what are we inheriting” — and the same figures support the opposite conversation when your client is the one being acquired.
Admin → Segments holds ordered rules that give a device its business unit, cost centre and persona. A device is matched against the rules in order and takes the first one that fits; lower order numbers are considered first. Rules can apply to any account or to one.
These rules decide two things elsewhere in TALON: what Chargeback bills, and who counts as a VIP on VIP Monitoring. Segmentation is where fleet data starts speaking the client's org chart, so it is worth doing properly and once.
The tiles count rules, business units and VIP rules. Every rule shows who changed it and when.
Optimize → Sustainability estimates energy and carbon from the device estate. Reports on one client at a time.
Pair it with Smart Asset Refresh: the donate-candidate count is the part of a refresh programme that keeps hardware in service rather than sending it to disposal, and it is the number an ESG report wants.
Automate → Actions → Library lists every remediation action available to run against a device, with the parameters each one takes and the platforms it supports. Search by name, description or parameter, and filter to Windows or macOS.
The library is read from Aternity, so it reflects the actions your tenant actually has, not a generic catalogue.
The Run an action panel at the top of the Library tab is deliberately hard to fat-finger. Pick the client in the header, choose the action, type the device name — then type the device name a second time to confirm before the Run action button will do anything.
That second field is the whole point: self-healing only counts when the guardrails are strong enough to let a junior technician use it. Every run is recorded in the Audit Log with who ran it, against what, and the result.
On preview builds, execution is switched off — the form is present so the flow can be reviewed, and the screen says so in a banner. See A button says the build cannot do that.
Actions → Signing signs a PowerShell script so Aternity will accept it as a remediation action. Upload a .ps1 file up to 512 KB; the file is signed and returned, and is not stored.
Only the first of three steps happens in TALON. The screen spells out the other two, because a script that is signed but not trusted fails on the device with a signature error that mentions none of this:
Sign it here. You get back a ZIP containing the signed script, Aternity-Remediation-Certificate.cer, an import helper and a README.
Trust the certificate on every device that will run it. Import the .cer into Trusted Publishers on each device — the included Import-RemediationSigningCertificate.ps1 does it, run as administrator. Once per device, not once per script.
Upload the signed script to Aternity. Gear icon → Remediation → New Action, and upload the _signed.ps1 from the ZIP — not your original.
Automate → Query asks the data source directly, for the questions the dashboards do not cover. Search across 129 data sets — account information, account licences, account user details, all activities, anomaly detection incidents, application events, application resources hourly and the rest — each listing how many fields it exposes.
Queries run against the same live source every screen reads, so a Query Builder answer and a dashboard answer agree. No API scripting is needed, which means the one-off question a client asks on a call can be answered on the call.
Query results export the same way every other table in TALON does, through the Export button. A query you run repeatedly is a good candidate to raise as an enhancement through Bug Reports & Enhancements — the dashboard you have not got yet is often a query someone already runs weekly.
Usage → Dashboards shows which Aternity dashboards people open and which nobody does: total views in the window, distinct dashboards opened at least once, and how many accounts show any usage at all, with a ranked bar chart of the most-opened boards.
It is the adoption evidence for a QBR — and the argument for retiring a dashboard nobody has opened in a month.
Usage → Sign-ins reports who last signed in to each account and which accounts have gone quiet: total logins, stale accounts against the configured stale-days threshold, and a per-account table with logins, last login, days since and whether it is considered stale.
Usage → Changes records configuration and inventory changes across accounts, with counts of changes and accounts affected. It is the Aternity-side change record; for changes made inside TALON itself, use the Audit Log.
TALON's AI features run on your provider account. You add a provider key on API Integration; TALON holds it server-side and calls the model on behalf of whoever is using a feature. Nobody signs in to anything, and no AI usage is billed through RavenTek.
That is what makes the features approvable: your compliance team gets to choose the vendor, the model and the tenancy. If no provider is configured, features fall back to deterministic output rather than failing — see What happens with no AI key configured.
On Admin → Platform → API Integration, Add a provider registers an account with a model vendor: the vendor, the model identifier and the key. Saved providers show as in use, with the model, the vendor, and who last changed it and when. Test runs a minimal call and reports the upstream result verbatim.
Provider tests are audited — look for admin.api_provider_tested in the Audit Log.
Under Where each feature gets its answers, every AI feature binds to a specific provider. Alert analysis can run on one model while another feature runs on a second — split them when a feature needs something cheaper, faster, or kept inside a particular tenant.
Because one save wires a new provider into every feature that points at it, changing a provider changes answers on screens the person saving may not be looking at. Change it deliberately.
“Tell Me Why” is TALON's AI-generated root cause analysis. It runs on the provider you configured for that feature, over the figures already on the screen — alert movement, crash stacks, account health — after they have been through PII sanitization.
Treat the output as a first hypothesis with the evidence attached, not a verdict. The underlying figures are on the same screen for exactly that reason.
Before any payload reaches any provider it passes through TALON's sanitizer. Usernames, email addresses, device names and other direct identifiers are SHA-256 hashed, so the model sees a stable token it can reason about without ever seeing who or what it belongs to. The mapping is not sent.
Every call is logged, and there is a kill switch that stops AI calls instance-wide without unconfiguring anything.
Every AI call passes through sanitize → router → audit. No raw identifiers leave the TALON instance.
AI responses are cached so that re-opening a screen does not re-bill you for the same answer. If you have changed something and want a fresh analysis, the cache can be cleared — note that the cached report data on Instance Settings is a different store, holding Aternity figures rather than AI answers.
With no provider configured, AI-backed panels fall back to deterministic summaries computed from the same figures — less narrative, no external call, no cost. Nothing breaks and no screen goes blank.
This is also the honest way to trial TALON before a provider decision has been made.
Admin (gear) → Users lists who can sign in to the instance and what each of them is allowed to do. Each row shows the person, status, how they sign in (password or SSO, with a no 2FA badge where second-factor is not in force), their roles, and when they last signed in.
From the row you can add or remove roles, and lock or unlock the account. All of those are reversible. Deleting an account and resetting a password are not, and both are recorded in the Audit Log.
Users → User Scope restricts which clusters and accounts each person can see. It is how you let a technician work a subset of the portfolio without seeing the rest of it.
Blank is not the same as none. An empty scope means the person sees everything, not nothing. Administrators are always unrestricted and cannot be narrowed here.
If an account is missing from someone's client picker but present in yours, this screen is the first place to look.
Users → Access Requests holds people asking to be let in, on Waiting, Approved and Denied tabs. Each request shows the name, the address, the email domain, when they asked and how — typically sso.
Approve and create the account provisions the account in one step, with the default role. Decisions are emailed if Email Configuration is set up.
Admin → Access → SSO Integration reports whether people can sign in with their Microsoft account, and what happens when they do. TALON uses Microsoft Entra ID over OpenID Connect, configured as a single-tenant app registration.
First sign-in provisions an account automatically, with the instance's default role.
Only the email domains on the allow-list may sign in.
TALON asks Microsoft for openid, profile and email — enough to learn who someone is, and nothing about their mail or files.
The screen also displays the directory (tenant) ID and the other resolved settings, so you have something exact to quote when asking whoever runs the Entra tenant to change something. The settings themselves are supplied to the service as environment variables and take effect on restart; the client secret is held server-side and is never sent to the browser, so it cannot be displayed even in principle.
Admin → Platform → License Status reports what this instance is licensed to do, and the keys RavenTek's management tooling uses to reach it: the instance ID, whether the control plane is reachable, whether licences can be verified, the licence itself, and who it was issued to.
Generating a new key immediately invalidates the previous one — which is what RavenTek's tooling is currently authenticating with. Do it only in coordination with RavenTek support.
Platform → Email Configuration holds the Microsoft Graph application TALON sends mail through — alert notifications, scheduled reports and access-request decisions. Until it is filled in, the screen reads Not set up and TALON cannot send email at all.
TALON signs in as the application itself rather than as a person, so the app registration needs the Mail.Send application permission with admin consent granted. The send mail from address must be a real mailbox in the tenant that the registration is allowed to send as — it is the address recipients will see.
The check button is the useful half of this screen: it tells you whether email is actually going to go out, without waiting for an alert to fire.
Platform → Instance Settings reports how the deployment is configured — the idle timeout before a session is signed out, and how many failed sign-ins lock an account. Those are set where the instance is deployed, not from this screen; they are shown so the current values are knowable.
The one action here is Discard cached figures. TALON stores the figures it pulls from Aternity so screens open quickly; clearing that store makes the next load fetch everything again. Nothing is lost that cannot be pulled again, but the next few screens will be slow and re-pulling consumes Aternity API quota.
Note that an account locked by failed sign-ins is a different state from an administrator locking it on User Admin.
Platform → Alert Thresholds defines what has to happen before TALON calls something a problem. Four groups of thresholds, on their own tabs:
My Live Alerts — drives the background live-alert run for your user, so changes here affect the severities stored for your next run.
Account View Exec — the verdict wording on the executive health card.
Desktop Health Scoring — how device health is graded.
Device Refresh — the weights behind refresh recommendations.
Each measure has thresholds by value (DXI below 70 is a warning) and by delta (a drop of 3 or more is a warning, 5 or more is critical). Every field shows its default underneath, and the header tells you whether anything is currently off-default — so a threshold someone tuned six months ago is visible rather than folklore.
Admin → Audit records every administrative action on the instance: when, who, what action, what it acted on, the result and where it came from. Filter by date range, action, user or result.
Scheduled and manual alert scans are audited like anything else — alerts.run entries carry the run number — alongside entries such as admin.api_provider_tested and control_plane.license_status. The log exports, which is what an auditor asking “who changed that” actually wants.
Admin → Reference → About Talon states the build you are on and what it is. It also carries the honest caveat that the version label shown there is maintained by hand and is not tied to a build number — so when reporting a problem, quote the date rather than the version.
It links onward to documentation, and to the preview access terms, DPA and subprocessor list.
Reference → Beta Program sets out what a preview build means for the numbers you are looking at: features may change without notice, availability is not guaranteed, and the build is offered as-is under your preview access terms.
It is specific about what “data may be incomplete” means, which is more useful than the usual disclaimer:
Some screens show fewer rows than the source holds — where that is known, the screen itself says so.
A few measures are computed over a window the screen cannot name, so two screens can quote slightly different figures for the same thing and both be right.
Where a figure is estimated rather than measured, the screen says so. If it does not say so, it is measured.
The rule that follows: do not make an operational decision on a preview figure alone — check it against the source first. Your acknowledgement of the terms is stored as a flag in your browser only.
Reference → Bug Reports collects what people using TALON have told RavenTek is wrong or missing. Reports arrive from the Feedback button in the bottom-right corner of every screen, and carry the page the reporter was on, their viewport, screen and browser.
The tiles count all reports, still open, resolved, bugs and enhancements. Each report can be re-classified and annotated with notes as it is worked.
Reference → Full Report lays every dashboard out as one printable document, scoped to your selected account and time window, with the preparation date and the source stated at the top. Tables are capped for length — the screens themselves remain the place to see everything.
Print or save as PDF opens your browser's print dialogue. Two settings matter: choose Save as PDF as the destination, and turn on Background graphics under “More settings” — without it the branding and the coloured bands do not print.
Some screens report on one client at a time and cannot be shown across the whole fleet — My Live Alerts, Startup, Resources, App Rationalization, EOL Software Risk, Chargeback, ESG / Green-IT and Device Refresh among them. They say so plainly rather than showing a partial figure.
Choose a client in the header picker and the screen fills in. This is a deliberate limit, not an error.
TALON stores the figures it pulls from Aternity so screens open quickly. If a screen is showing something you know has changed, an administrator can clear that store with Discard cached figures on Instance Settings — the next load then fetches everything again.
Two caveats: the next few screens will be noticeably slower, and re-pulling consumes Aternity API quota. Also check the time window in the header before assuming a figure is stale — a 14-day window includes days you may not have meant to include.
Three causes, in order of likelihood: the account's cluster is not selected on the Connector; the connector has an account focus set that narrows the read to one account; or your User Scope restricts which accounts you may see.
Compare with an administrator's view — administrators are always unrestricted, so if they can see it and you cannot, it is scope.
Check the SSO Integration screen. It states whether single sign-on is enabled, which email domains are allowed, and the directory it is pointed at. The most common cause is an address outside the allow-list.
If the instance requires approval, the sign-in attempt creates an entry on Access Requests instead of an account — an administrator has to approve it. Configuration itself is supplied as environment variables and takes effect when the service restarts, so a change made minutes ago may not be live yet.
After the configured number of wrong passwords — shown on Instance Settings — an account is locked out. That is a different state from an administrator locking it on User Admin, which is done deliberately and undone the same way.
Sessions also end after the configured idle timeout, which is shown on the same screen.
Open Email Configuration and run the check. If it reports Not set up, the Graph application details have never been filled in and nothing will send.
The two failures worth knowing: the app registration is missing the Mail.Send application permission or its admin consent, or the send mail from address is not a real mailbox the registration may send as. A rotated client secret that was never updated is the usual cause of a configuration that worked last quarter and does not now.
Check API Integration. Is a provider configured and marked in use, and is the feature in question bound to it under Where each feature gets its answers? Use Test — it runs a minimal call and reports the upstream error verbatim, which usually names the problem outright (rotated key, retired model, exhausted quota).
With no provider configured at all, features return deterministic summaries rather than failing — that is the fallback, not a bug.
Preview builds switch off a small number of actions and say so in a banner on the screen itself. The reasoning is stated each time, and it is the same in every case: the action is not reversible from that screen.
Connector — saving and disconnecting are off, because every screen reads through the one connector and a wrong save takes them all down at once. Reading and testing work normally.
API Integration, Email Configuration, License Status — saving stored credentials is off, because a stored secret can never be read back, so a mistaken save cannot be undone by anyone.
Actions — remediation execution is off, because it would act on real machines. The form is present so the flow can be reviewed.
User Admin — deleting accounts and resetting passwords are off. Locking, unlocking and role changes work normally, because they are reversible.
Everything else on those screens reads, validates and tests as it will in production.
Open a ticket with the ManagedDEX customer support team, email RavenTek support, or send it straight from the portal with the Feedback button in the bottom-right corner of every screen.