Cenovel core operating guides
Reviewed against the application source on 2 October 2026. Describes the current development release; not a deployment certificate.

Discovery and identity matching
Find devices on approved management networks, resolve access and identity questions, and review what enters the inventory.

What discovery does

Find devices gathers evidence from addresses on the management networks recorded in Cenovel. Found devices is the review queue for what answered, what needs access, and what could not be identified. Finding an address does not, by itself, add a new inventory asset or approve its physical location.

Use the site view when you know where the equipment belongs. Use the district view when reviewing networks and discoveries across sites. A result may identify a switch, access point, server management controller, or another device. Identification and successful collection of every hardware detail are separate outcomes. An Administrator EX can also turn on a nightly find, which is off by default; it only fills Found devices, and nothing is added until someone adds it.

Prepare the network and access

Only private management networks are accepted. Each network can be at most a /22, with up to 256 listed networks and 4,096 addresses in one find. Divide larger ranges into appropriate approved networks. These limits keep the selected scope explicit; a public address is not a supported discovery target.

1. Confirm the site exists and, for switches, that its closet has been recorded. A switch must be assigned to a closet at the selected site before it can be added from the queue.
2. Add or enable the intended private management network under Networks. Use its network address, such as 10.20.30.0/24, rather than a host address with a network suffix. A single address can be entered as a /32.
3. Configure an active credential in Governance › Monitoring › Configuration › Access. Only Administrator EX can create or change credentials; ask one if the site has none that applies. Device CLI credentials support SSH; SNMPv3 credentials support SNMP discovery. A site credential must cover the selected site. A district credential can be used across sites.
4. For SSH, verify the device fingerprint through a trusted source before approving a new key. A new-key result means identification stopped at the trust check; it is not an invitation to repeatedly change passwords.
5. Check your permissions. Site discovery changes require equipment-page edit access and Operator or above. District discovery follows Monitoring permissions. Adding a server also requires Monitoring edit permission.

Run a find and review the result

The current finder can use SSH, SNMPv3, or server management evidence according to the available credentials and responses. It does not promise to collect both SSH and SNMP evidence for every found device. A successful SSH identification can finish that address before SNMP is attempted.

Ignore records a review decision for a waiting item. The same device remains ignored when found again. Use Ignore for a deliberate decision, not as a substitute for correcting missing access or an unresolved serial conflict. The queue can be filtered to Waiting for review, In Cenovel, Ignored, or All.

1. Open Find devices for the intended scope and start a find, or choose a single address within the approved scope. Watch the run status rather than starting repeated copies of the same search.
2. Open Found devices and inspect the reported name, vendor, model, serial, address, method, credential label, and last-seen time. When a site collector performed the read, the result identifies that collector.
3. Read the explanation beside a result that needs attention. Correct the credential or trust problem, then find the address again. Stop a run when its scope is wrong or further attempts are no longer useful.
4. For an identified device awaiting review, open Add. Confirm the site, closet where required, device name, and catalog model. Review the model diagram and the available interface evidence before confirming the model.
5. Choose Add to Cenovel only after the identity and placement are settled. If the item or selected model changed while the form was open, reload and review the current information before trying again.

Understand access and partial results

A timeout, closed service, or credential that Cenovel cannot open is not proof that hardware was removed. Read the run explanation and the observation time. Repeated credential refusals are remembered for a limited window, and remaining attempts can be held; immediately repeating the find may therefore try fewer credentials.

Partial component reads must not turn an omitted power supply or fan into a removal. A missing serial at an already identified attachment also does not establish a replacement. A positively reported changed serial is different evidence and can identify a replacement. Complete empty inventory can establish absence, while the former inventory asset remains available as a record.

A successful SSH command is not enough to prove a complete hardware inventory. If a supported Junos, EXOS, or IOS/IOS-XE chassis inventory command returns text with no recognizable chassis or member identity, Cenovel records a parse failure and treats the read as partial. The same protection applies when the output contains more recognizable member-row headings than the parser can recover as members. The successful connection still counts as reachable; the unreadable inventory does not prove component removal.

Cenovel also treats malformed numbered Junos member, PIC, transceiver, power-supply and fan-tray rows as incomplete evidence. An unreadable member or PIC heading cannot give its children the previous heading’s location: those children are skipped until a valid sibling or ancestor is found. Existing components remain recorded when the inventory is incomplete. This protection has passed automated checks but has not been verified against physical equipment, and it may not be in your installed version.

New SSH key | No credential was sent to the untrusted key. Verify the fingerprint, approve it through the key review, and find the device again.
Needs a credential | An address answered, but an applicable sign-in is missing. Add or correct a credential covering that site.
Could not sign in | The device refused an attempted sign-in. Check the selected profile and device account. Some further attempts may be held to avoid account lockout.
Not identified | The device answered but did not provide a supported identity. Review the reported method and details rather than selecting a plausible model by guesswork.
Some details missing (no separate label) | Some identity or hardware information was collected, but not every requested detail completed. Keep the successful evidence and investigate what remains missing.
Found by earlier discovery | The item was carried over from the earlier device discovery, before Find devices replaced it. Its explanation gives the date it was found; find the device again to collect current evidence.

How existing identities are treated

When adoption checks existing inventory, a unique live serial match takes precedence over the device name. If more than one live record carries that serial, Cenovel requires review instead of choosing an arbitrary record. Without a usable serial match, a name match is limited to the selected site and its locations; duplicate names also require review.

A result already recognized as an existing asset directs you to that asset to review its whereabouts. It is not another Add opportunity. A serial found only in deleted inventory is surfaced as a reappeared asset. Discovery neither restores it automatically nor creates a replacement copy; if it is back in service, restore the deleted record from the found item's Restore button or from Recently deleted; otherwise ignore the found item.

For example, a switch may answer at a new address under a new hostname while retaining its unique serial. Review the existing record and location rather than creating another asset for the new address. Conversely, the same hostname with a different serial may represent replacement hardware. Resolve the replacement from the existing device page instead of merging the two identities.

Finish the review

When SSH discovery supplies component evidence, adoption preserves the time that evidence was actually collected. Adding the device does not make an old observation fresh. A subsequent scheduled read updates the evidence and reconciles the same chassis and component identities when their reported identity remains unchanged.

- Confirm the asset opens under the intended site and closet, and distinguish reported whereabouts from an approved inventory move.
- For a stack, check each reported member and serial. Incomplete or contradictory member evidence is not permission to assign all components to the stack head.
- Review component findings separately from the chassis result. A readable switch can still contain a part whose catalog identity needs a decision.
- Keep unresolved results visible until the access, model, or identity issue is understood. A successful find is evidence for a decision, not a guarantee that every device feature was read.

Limits of this guide
This guide is based on the application source and automated checks with simulated devices. It does not claim validation against live production devices.
Device family, firmware, credential privileges, collector availability and partial responses all affect what evidence is available for review.
No automatic task creation, general mapping inbox or bulk identity-merging workflow is promised.
Some corrections described here, such as keeping the original observation time on adoption and rechecking a server-controller credential's site before sign-in, may not be in your installed version.

Device reads and monitoring
Set up SSH and SNMP access, understand the shared polling schedule, and distinguish a fresh device answer from missing, incomplete, or older evidence.

Start with the device and its evidence

Monitoring reads enrolled devices at their recorded management addresses. Discovery establishes an identity; monitoring revisits it to collect the information that device and its access method support. A device answering does not mean every port, neighbour, stack member, or power supply was read successfully.

Open Monitoring to review SSH, SNMPv3, ports and endpoints, and site collectors. Then open the device for its individual evidence and observation times. Use the summary to find a problem, but use the affected reading to decide what happened. An old successful reading remains useful history; it is not a fresh health check.

Prepare credentials and trust

Give the device account the access needed for the supported read commands and tables. A successful sign-in can still leave individual commands unavailable. After rotating a credential, check that the intended collector has the current version of the credential before treating a missing collector read as a device fault.

Publishing an approved SNMP read list does not authorize collector reads. Activating that exact list authorizes only eligible collectors that have the same list installed and the needed capabilities. If automatic polling is already enabled, eligible scheduled reads can use that activation; activation does not enable the polling schedule itself. Retiring the activation blocks new claims using it and leaves the polling schedule unchanged.

An explicitly selected SNMP credential must still cover the device's current site when a read starts. Restricting a district credential to another site stops those former bindings from using it. Select a credential authorized for the device's site, or correct the profile's scope, before retrying. A scope refusal does not create a device-down observation or refresh the last successful reading.

For SSH, a site credential needs an independently established target site: the read request’s site or the site recorded with the trusted host. A credential cannot establish that site merely by belonging to it. Older saved reads with neither source of site ownership must be corrected before a site credential can be used; verifying the host key alone does not establish site ownership.

1. Confirm the device's site, management address, and intended monitoring method. An address change or replacement must be reviewed against the existing identity before trusting new results.
2. In Governance › Monitoring › Configuration › Access, choose an active Device CLI credential for SSH or an SNMPv3 authPriv credential for SNMP. Check whether its scope covers the device's site. A district profile and a site profile are different choices; the presence of some saved credential does not prove this device has usable access.
3. Enter the device account and the required secret. For SNMPv3, match the username, authentication protocol, privacy protocol, and their secrets to the device configuration. For SSH, use the configured password or private key. Existing secrets are write-only in the form; an empty displayed secret is not evidence that none is stored.
4. For SSH, verify a new or changed host fingerprint through a trusted source before approving it. A changed key needs an explicit rotation decision. Do not approve an unexpected key simply to make the read succeed.
5. For governed SNMP collector reads, review device identity candidates when requested. Verifying an engine identity pins future reads to that exact identity; retirement removes that active claim. Record the reason for each identity decision.

Use the shared schedule

Applicable SSH and SNMP health, ports, neighbours, and component reads belong to the same collection cycle. There is no separate nightly port interval or priority-site cadence in this policy. A cycle is a collection window, not a promise that all devices finish simultaneously or every requested class succeeds.

Timeouts and the number of devices read at once remain under Collection limits. They constrain work within a cycle rather than create another schedule. Work that cannot finish before the cycle deadline is incomplete; the next cycle provides another opportunity. Missed intervals do not become a backlog of duplicate cycles. Changing the interval never refreshes old observation timestamps.

1. Open Governance › Monitoring › Configuration › Schedule and read the saved Automatic polling state.
2. Enable automatic polling and set Polling interval (minutes). The starting interval is five minutes; the accepted range is a whole number from 5 to 1440. An installation that previously had automatic polling off can retain that choice.
3. Select Save schedule and wait for the saved confirmation. Changing this policy requires Administrator EX with Monitoring edit access.
4. If another editor changed the policy, choose Reload schedule, review the current value, and make your change again. If the schedule cannot be read, reload it; the error does not establish whether automatic polling is enabled.

Know what each method can contribute

An SSH-bound switch can use SSH for its supported regular readings and SNMP for ports when SNMP is available. Other enrolled targets follow their available methods and bindings. Controller-owned access points can be covered by their controller instead of receiving a direct read. Do not expect both transports to contact every device.

The shared policy described here governs these SSH and SNMP device reads. It does not establish that server management, controller integrations, notifications, or every other provider uses this interval.

Identity and health | Reported name, description, vendor or model, software family/version, uptime, reachability, response timing, and access failures.
Ports | Interface names, descriptions, administrative or operational state, speed, and last-change information. SNMP counter samples support traffic rates and error/discard changes.
Neighbours and endpoints | Reported neighbour names and port relationships; supported bridge/address tables can show endpoint MAC/IP associations. These are observations, not approved inventory moves.
Chassis and components | Supported member identities, serials, modules, transceivers, and power/environment evidence. The available detail depends on the device family and completeness of its response.
Additional SSH detail | Supported command output can supply interface, PoE, environmental, stack, media, optical, switching, or statistics detail. Unsupported commands leave that class unavailable.

Understand site collector participation

A reporting collector is available to be considered; its heartbeat alone does not show that it polled a device. Check the collector activity, cycle or job outcome, and device observation. The shared scheduled path selects eligible site collectors for supported full SNMP switch reads. Scheduled SSH, manually enrolled targets, and unsupported scheduled collector bundles use the console path. Separately requested device commands and manual reads have their own collector eligibility checks.

Eligibility includes the correct site, an active and recent heartbeat, available capacity, the required capability, the current version of the credential, and matching approved collector software and read definitions. When no eligible collector is selected, the console can own the read. Once collector ownership is committed, a collector failure does not trigger a second console read for the same assignment.

Accepted collector evidence must still pass identity, time, and completion checks before it updates live device data. An expired job, stopped collector, refused clock, or missing result is a collection gap. It must not be read as a synthetic device-down observation.

When another read is already running

A scheduled read, discovery, or a manual request may already be using the same management address. Cenovel keeps that address reserved until the earlier connection has closed. A busy or stopping reader means the new request was deferred; it is not a new device failure and does not refresh the last successful reading.

Wait for the existing request to finish before retrying. A deadline or missing collector response does not prove that its device connection stopped. If the address remains busy, inspect the original job and collector instead of repeatedly submitting new requests.

When a collector eventually confirms that an expired request has closed its connection, the address can become available again. That late confirmation does not turn the expired request into a successful fresh reading. A later request must collect its own evidence.

Vendor evidence captures distinguish a device that could not be read now from a fresh answer. Earlier stored evidence remains available with its original timestamp. Check that timestamp before describing the capture as current.

Remote manual reads require approved collector software that supports permission before each connection and reliable completion reporting. Check your release notes for the collector version that supports this. Installing a version alone does not grant approval. Remote manual requests that would recursively read additional endpoint addresses are currently refused; they do not silently claim those endpoints were read.

Read freshness one class at a time

Compare the latest attempt with the last complete reading. A recent failed attempt can coexist with an older complete port table. SSH and SNMP retain their own attempt and successful-observation times; an SSH answer does not refresh an SNMP counter sample.

Complete evidence can replace the previous facts for its class. Partial, failed, truncated, or unsupported evidence cannot claim a new complete observation. Earlier useful values can remain visible with their own timestamps. A blank field therefore means unknown or unavailable unless the device positively reported an empty value.

Traffic needs comparable counter samples. The first sample establishes a baseline. A reboot, counter reset, changed interface index, collector change, or unusable interval can prevent a rate calculation. No rate is not zero traffic. Likewise, an unread power table is not proof that every supply is healthy, and a partial component inventory is not proof that an omitted part was removed.

Port summary counts describe the latest recorded attempts within the displayed period, currently the last 24 hours. They are not a guarantee that one whole cycle completed or that every enrolled device was read.

Respond to failures in order

If many devices become silent together, investigate Cenovel's reach to the management network and shared credentials before declaring many independent hardware failures. Observation conditions can hold outage handling while the monitoring system itself lacks reliable visibility.

Schedule unavailable | Reload the saved policy. If it remains unavailable, report a monitoring service/storage problem; do not infer an enabled schedule from an old value.
Not set up or no applicable credential | Check the selected method, profile state, site scope, and stored access details before retrying.
Authentication refused or trust changed | Verify the device account or fingerprint/engine identity as appropriate. Correct the specific access problem rather than repeatedly submitting the same request.
Timeout or closed service | Check the management address, service availability, and the network path from the assigned console or collector. A timeout alone does not identify a failed chassis.
Collector silent, expired, or clock refused | Check its heartbeat, connectivity, time health, software/read-definition approval, credential version, and capacity. Inspect the existing job outcome before starting another manual request.
Partial or unsupported class | Open that class's explanation and timestamp. Check device support and command/table access; retain the successful classes while investigating what is missing.

Confirm recovery with new evidence

1. Correct the identified access, network, collector, or device issue and allow a subsequent cycle to run. Avoid repeated manual requests while earlier work is unresolved.
2. Confirm that the affected transport now has a new answer and that the specific missing class has a new complete observation time.
3. Review component and outage detail separately. A working management connection does not establish that an unread power supply recovered. A missing serial does not, by itself, establish a replacement.
4. Check the resulting device facts and incident history. Recovery should follow appropriate new evidence; acknowledgement or an interval change does not substitute for that evidence.

Limits of this guide
Reader coordination and the collector permission check described here may not be in your installed version, and they need a site collector release that supports them. Check your release notes before relying on them.
Automated checks used simulated devices. They do not establish behavior on every physical device or polling capacity for a whole district.
Enabling the hardware-table registry is separate from enabling automatic polling; collector, credential, identity and policy checks still apply.
Older poll times are kept to the second. Missing historical readings cannot be recreated later. Unsupported device features and incomplete replies still limit what you can conclude.
The credential-scope and SSH target-site checks described here may not be in your installed version.

Juniper Mist
Connect a Juniper Mist organization with a read-only token, map its sites by hand, and read Mist's disconnected report as Mist's view rather than a Cenovel observation.

What Cenovel reads from Mist

Cenovel can read one or more Juniper Mist organizations: their sites, device status, device inventory, device events and infrastructure alarms. It only reads. Nothing in Mist is changed, and Cenovel keeps client counts, not the identities of connected clients.

Each connection is read every five minutes. Sites and device status are read every time; device inventory is read at most about once an hour; events and alarms are read from where the previous read stopped. Each fact on the Mist panel carries its own time.

Mist's report about a device and Cenovel's own reachability check are different facts. Mist can say a device is disconnected from the Mist cloud while it still answers Cenovel, and the reverse. Cenovel shows them separately and never turns one into the other.

Before you connect

- Outbound access: Cenovel reaches Mist over HTTPS (TCP 443) to one host, the API host for your Mist region. Allow only that host. Cenovel refuses redirects to any other host.
- Token: create an organization API token for Cenovel alone, with read-only privileges. Optionally restrict it to the appliance's public address in Mist. A token that can change the organization is accepted with a warning that Cenovel needs only read access.
- Organization ID: find it in the Mist portal under Organization › Settings.
- Permission: only Administrator EX can connect, change or remove a Mist connection.

Global 01 | manage.mist.com | api.mist.com
Global 02 | manage.gc1.mist.com | api.gc1.mist.com
Global 03 | manage.ac2.mist.com | api.ac2.mist.com
Global 04 | manage.gc2.mist.com | api.gc2.mist.com
Global 05 | manage.gc4.mist.com | api.gc4.mist.com
EMEA 01 | manage.eu.mist.com | api.eu.mist.com
EMEA 02 | manage.gc3.mist.com | api.gc3.mist.com
EMEA 03 | manage.ac6.mist.com | api.ac6.mist.com
EMEA 04 | manage.gc6.mist.com | api.gc6.mist.com
APAC 01 | manage.ac5.mist.com | api.ac5.mist.com
APAC 02 | manage.gc5.mist.com | api.gc5.mist.com
APAC 03 | manage.gc7.mist.com | api.gc7.mist.com

Connect Mist

Use Check token at any time to ask Mist whether it still accepts the stored token. Use Change to rotate the token, or to correct the region or organization; Cenovel checks the new details with Mist before saving them. Read now starts a read straight away and shows that it is working until the read finishes. Remove stops Cenovel reading Mist and erases the stored token; delete the token in Mist as well. What Mist reported earlier stays in history.

1. Open Governance › Monitoring › Configuration › Access and find the Juniper Mist panel. Choose Connect Mist.
2. Enter a name, choose the region your portal address names, and paste the organization ID and the token.
3. Choose Check and connect. Cenovel checks the token with Mist before saving anything. If Mist refuses it, the drawer says why and nothing is saved.
4. After a successful check, Cenovel stores the token sealed, never shows it again and starts the first read. Mist sites appear after that read.

Map Mist sites to Cenovel sites

Cenovel never maps a Mist site by itself. Each Mist site is listed as Not mapped yet until an operator chooses a Cenovel site, or chooses Ignore. When a Cenovel site has exactly the same name, the row offers it as a one-click choice; it is still only applied when you choose it. Only mapped sites place devices or raise Mist's reports at a Cenovel site.

A Mist site that is renamed keeps its mapping. The row shows the earlier name and the date of the rename until you choose Noted. A site that disappears from Mist's complete site list is shown as no longer listed, with the date, until you choose Remove mapping; its devices keep their last known site. If Mist lists it again it returns to be mapped. A partial site list never marks a site as missing.

How Mist devices are linked to records

Cenovel links a Mist device to an inventory record by serial number first, then by hardware address. It does not match by name.

When the match is not clear, nothing is linked and the device is listed under Devices not linked until somebody decides, with the reason. Examples are two Mist devices with the same serial, a serial or hardware address carried by more than one record, a hardware address that belongs to a record with a different serial (possibly a replaced unit), or two Mist devices claiming the same record.

While Mist has described an access point recently, Cenovel does not poll that access point directly; its closet, switch and port still come from the switch. If Mist's description goes stale, or the link is contested, Cenovel polls the access point itself again where it has a management address.

Mist reports this device disconnected

When a read shows Mist reporting a linked device on a mapped site as disconnected, Cenovel opens an outage named Mist reports this device disconnected, with Warning priority. It carries the time Mist gives for the disconnection, when known, and the time Cenovel read it. When a later read shows Mist reporting the device connected, the outage closes with the words Mist reports it connected again.

This is Mist's view of the device's connection to the Mist cloud. It is not the same as Access point not answering Cenovel, which comes from Cenovel's own reads. Check both before deciding where the fault is.

Nothing is concluded from a device whose status Mist does not give, a device that is not linked or is contested, or a site nobody has mapped. A failed read never opens or closes this outage.

Planned work can quiet it. A maintenance window on the access point, offered as Juniper Mist's disconnected report, quiets that report while the window is open.

When a read fails or Mist asks Cenovel to wait

- A failed read is shown as The last read failed, with its time and the reason in plain words. The last successful read keeps its own time. A failed read says nothing about the devices.
- If Mist's site list or device status cannot be read, nothing from that read is stored. If only inventory, events or alarms fail, the rest of the read is kept and the failed part is recorded on its own.
- If Mist's list changes while Cenovel is paging through it, nothing is concluded from that read and the next read starts over.
- If Mist asks Cenovel to slow down, Cenovel waits for the time Mist gives. The panel shows Waiting before the next read and when the next read can start; Read now is unavailable until then.
- Cenovel limits itself to 2,500 Mist requests an hour for each connection, half of what Mist allows one token, so other tools keep headroom. The panel shows the requests used this hour.

Keep the token alive

Mist removes API tokens that go unused for 90 days. Cenovel uses the token on every read, so an active connection keeps it alive. Pausing the connection stops reads and stops Cenovel watching anything Mist reports; a connection paused for about three months will need a new token.

The panel warns when the token has gone unused for 60 days, or for 30 days on a paused connection. After 90 days it says the token has probably been removed. Create a new read-only token in Mist and rotate it with Change.

Optional webhooks

Cenovel works without webhooks: it polls Mist with outbound HTTPS only. Webhooks let Mist deliver device events and alarms sooner, but they need Mist's cloud to reach the appliance inbound over HTTPS with a publicly trusted certificate.

Webhooks are off until you choose Turn on webhooks. Cenovel then shows a secret once. In Mist, add an HTTP POST webhook to the path shown, on the appliance's public address, with that secret. Rotate secret makes a new one; Turn off stops accepting deliveries while polling carries on.

Cenovel accepts a delivery only when its signature matches the secret, it names this organization and it is within the size limit. Refused deliveries are counted on the panel with the time of the last one. A repeated delivery is not processed twice.

A delivery is stored as an event or alarm. It never opens or closes an outage by itself: outages come only from Cenovel's own reads of Mist's device status.

Limits of this guide
This guide is checked against the application source and automated runs against a simulated Mist organization built from Mist's published API. It has not been proven against a real Mist organization.
How long Cenovel keeps stored Mist events, alarms and device movements is not yet governed by a retention setting.
Only Juniper Mist's disconnected report opens an outage. Stored device events and infrastructure alarms do not raise outages.
Some behavior described here may not be in your installed version. Check your release notes.

Models, vendors, and discovery mappings
Maintain the product catalog, review discovered model assignments, and use the implemented vendor/product matching and diagram controls safely.

Separate the product from the individual asset

A model describes a product shared by multiple pieces of equipment. An asset describes an individual item, including its serial and recorded location. The vendor catalog identifies the manufacturer associated with a model. Correcting a product record is therefore a different decision from replacing a device or moving an asset.

Discovery reports the product wording a device supplies. That wording may differ from the catalog name because of punctuation, a shortened family name, or a hardware suffix. Cenovel can suggest a match, but an operator must still confirm the actual equipment before adding it. A familiar name alone does not prove the port layout or installed options.

Prepare the catalog

Component categories have a deliberate exception: a discovered part can remain without a known manufacturer. This preserves uncertainty instead of assigning the switch vendor to an unrelated optic. Component models also receive the required component workflow fields. Treat an unknown manufacturer as an evidence gap to investigate, not as a reason to invent one.

A vendor used by a model cannot simply be deleted. Models used by assets or closets are also protected from deletion, including checks for records that may later be restored. Correct the affected relationships deliberately; deleting catalog entries is not a way to erase equipment history.

1. Open the model and vendor catalog pages available to your role. If editing controls are unavailable, ask an administrator to check the relevant page permissions instead of creating a substitute record elsewhere.
2. Create or verify the vendor first. Keep its name clear and use the available support website, support phone, website, and notes fields for information operators will need later.
3. Create the model with an exact, recognizable name and appropriate category. Ordinary equipment models require a vendor and category. Record the product or part number separately when it is known.
4. Review the model’s other available fields, including its custom fields, serial requirement, lifecycle information, and price where used. Do not enter a guessed part number just to make discovery match.
5. For network equipment, open Model diagrams and check the physical layout. Confirm that the selected product, front or rear face, member, socket types, and port numbering correspond to the actual hardware.

Review a discovered model assignment

Automatic name matching tolerates case and punctuation differences. An exact spelling is preferred where several normalized names exist. For duplicate catalog names, the resolver prefers the record already used by the estate, with a stable fallback for unused duplicates. This selection does not establish that duplicate products are interchangeable; review their category, part number, and hardware before consolidating anything.

Near-name candidates are suggestions, not automatic assignments. For example, a reported family name may be close to a catalog product with a longer suffix. Verify whether the suffix describes the same hardware or a different power, port, or airflow variant. A model absent from the catalog should not be filed under a merely similar product.

1. In Found devices, open Add for an identified device. Read the reported vendor and model, collection time, source, and any partial-evidence warning.
2. Review the proposed catalog match. The explanation distinguishes a reported-name match from a previously reviewed vendor/product rule. If there is no exact match, choose the model that agrees with the physical device.
3. Inspect the diagram and interface-to-socket review. Where no physical interface list is available, port coverage and positions have not been verified. Do not interpret a blank review as a successful comparison.
4. Confirm the exact model before adding. Changing the selected model clears the previous confirmation. If another person changes that model while you are reviewing it, reopen the review so the decision uses the current diagram.

Use the existing reusable matching rule

The Add review can offer “Remember” when the selected model is one of the supported near-name candidates and the discovered device reports a vendor. This records a reusable association between that vendor, the reported product wording, and the chosen catalog model. It applies to future finds; existing asset assignments are unchanged.

The remembered choice is intentionally limited. It does not replace an exact catalog match, does not create a rule when the vendor is unknown, and does not accept an arbitrary unrelated model as a standing match. If the same vendor/product already points to another model, review that conflict rather than repeatedly submitting a different choice.

In Model diagrams, open “Saved versions, affected equipment and matching rules” to inspect rules for the selected model. An authorized administrator can remove a rule after confirmation. Removing it preserves current device assignments and makes future unmatched finds require another decision. Reload before retrying if the rule changed while the panel was open.

Build and review a diagram from discovery

Model diagram discovery reads one scoped device to gather diagram evidence. It does not add that device to inventory. The operation requires equipment-page edit access and administrator authority, alongside a usable credential and the correct site scope.

The result provides reported interface names as a starting point. Review partial or truncated results, excluded logical interfaces, unsupported names, and the selected stack member. One model diagram describes one physical member. Junos port zero is translated to the diagram’s internal first position; compare the displayed mapping with the device rather than renumbering the source list by guesswork.

The history panel shows the latest 30 saved versions and up to 25 active equipment records using the model. Use that affected-equipment list to understand the reach of a shared diagram edit. A saved historical version is a review aid, not an instruction to overwrite the current layout without checking it.

1. Choose the face and device member, then inspect or enter the interface names.
2. Correct unsupported or duplicate mappings and supply missing physical ports when the evidence is incomplete.
3. Choose socket rows and the default socket type, confirm that the ports belong to the selected model, and build a draft.
4. Review the draft before Save diagram. Loading a historical version changes the draft only; saving updates the shared model used by its equipment.

Treat component identity separately

Same optic name, different reported part numbers | Keep the part numbers distinct. A shared description does not justify selecting the wrong product.
Reported manufacturer conflicts with the catalog | Review the manufacturer and serial evidence. Automatic linking must not silently disregard the conflict.
Third-party optic without its own manufacturer evidence | Do not assume the switch vendor manufactured the optic, even when a part-number candidate exists.
Partial or blank serial at an occupied attachment | Retain the established component identity until stronger evidence arrives. Missing identity is not a confirmed replacement.
New positively reported serial | Review the replacement evidence and its attachment. Preserve the former asset record rather than deleting history.

Limits of this guide
This guide is based on the application source and existing automated checks, not live-device verification.
The reusable rule available today is the vendor and product choice in Found devices, with per-model inspection and removal. A general mapping editor, bulk mapping import and mapping-generated tasks are not available.
A matching catalog name or generated diagram does not verify the physical product, its socket media or all optional hardware.
Permissions for catalog changes, diagram changes and discovery are checked separately; access to one does not grant the others.
Optic manufacturer matching was checked with supplied discovery readings, not physical devices.

Asset tracking and component replacement
Understand how observed hardware connects to inventory, what happens when a part changes, and when a person needs to resolve the record.

Keep identity, installation and placement separate

An asset is the continuing inventory record for an item. An installation observation says that a particular part was seen in a particular host or bay. Placement records where the organization says the asset belongs. These facts can disagree without meaning that the asset should be deleted.

A switch address identifies a place to read, not permanent hardware identity. A serial number, a trustworthy hardware address, the component's attachment and its model evidence help Cenovel decide whether a reading describes an existing item. A reported name by itself is not enough to prove that two devices are the same.

Before relying on automatic updates

- Enroll the network equipment and place it in the correct site and closet. Configure an active credential and management-network coverage that permits the required read.
- Review model and manufacturer records. Duplicate serials and ambiguous model names can prevent automatic matching even when the device answers.
- Confirm that the device reports the relevant hardware inventory. A successful login does not prove that every component command or table was read completely.
- Use an account with the permissions required for the inventory and monitoring actions. An observation does not grant the person viewing it permission to edit the asset.

Review a component change

1. Open the equipment and inspect its latest device reading, including whether the component inventory was complete.
2. Open the observed component and its linked asset. Compare its serial, model, manufacturer and attachment with the part that was installed.
3. Check whether Cenovel matched an existing asset, created a new one, retained weaker evidence for review, or reported a conflict.
4. For a replacement, review both the new installation and the old asset. Record the old item's actual destination through the appropriate inventory, repair or disposal workflow.
5. If the result is unexpected, retain the reading and inspect its time and completeness before changing inventory records to make them agree.

What the next supported hardware read can do

A new, identifiable part appears | Cenovel can match its serial to an existing asset or create an asset when its model can be resolved. Unsupported or ambiguous evidence remains a finding for review.
The same identified part is read again | The installation is confirmed. Repeated observations should not create a new asset each time.
A different serial appears in the same attachment | The installation changes to the replacement. The former asset is retained; replacement is not disposal.
The serial becomes blank for a previously identified part | Cenovel retains the identified installation at the same attachment and component kind. A blank serial is not proof of replacement, even if the table walk completed.
An explicit empty or absent bay is reported | The bay is recorded as empty or absent and is no longer linked as an installed asset. The former asset remains.
A complete component inventory omits a previously present part | The former installation can be marked removed for the same host and evidence source. Incomplete inventory, or a read from a different source, cannot support that same conclusion.
A partial or failed read omits components | Missing data is not treated as confirmation that every omitted part was removed.
A serial or manufacturer conflicts with inventory | Automatic matching is withheld. Review the device evidence and catalog instead of selecting an arbitrary match.
A deleted component is reported again | Cenovel retains the deleted asset and refuses to create a duplicate. A fresh report of that exact part can appear in the host’s Parts list without a live asset link. Review the restoration finding; rediscovery does not restore inventory automatically.

When readers report different levels of detail

A switch-level observation can confirm the same serial-numbered part without identifying the stack member that holds it. When the recorded member still belongs to that switch and its serial still matches the live host asset, Cenovel retains the more specific member installation. The switch-level reading keeps its own source and time; it does not refresh the older member-specific timestamp.

Fresh evidence from a different switch can supersede the former installation. A deleted host or a member whose serial no longer matches its asset does not receive this protection. Inspect the collection times and attachment details when the readers disagree; a broad observation alone does not prove a new member or bay.

Parts without serial numbers

A part without a serial may still be recorded by a stable, supported bay when it has a linked host asset and a resolvable model. That is a bay-based record, not proof of a globally unique physical item. Without sufficient attachment context, the part remains an observation rather than an individually identified asset.

This distinction matters when moving a serialless fan between two switches: the two bay observations alone do not prove that it is the same physical fan. Do not merge inventory items solely because their descriptions match.

Manufacturer and model rules

Cenovel considers reported part numbers and manufacturer evidence when selecting a catalog model. A compatible transceiver is not automatically manufactured by the switch vendor. Transceivers are excluded from switch-vendor inheritance; explicitly third-party components are also protected from that assumption.

For other components, the host model's manufacturer can supply a fallback only when the part reports no manufacturer, is not a transceiver, and is not explicitly third-party. A reported manufacturer that cannot be resolved is not replaced by the host vendor.

Following an asset to another address or site

Tracking is off by default. An administrator with Monitoring edit permission can configure it. In observation-only mode, Cenovel can record evidence of a possible move without transferring monitoring. Automatic transfer requires active tracking at the site, a unique supported asset and monitoring subject, current evidence, a serial-confirmed SSH or SNMP identity read, and unambiguous site-network coverage. SSH needs the device's host key to be trusted at the new address; Cenovel carries trust over by itself only when the device presents the same key that was trusted at its previous address. SNMP requires authenticated, approved engine identity.

A hardware-address match can help identify a candidate, but it does not by itself authorize automatic monitoring transfer. Shared stack addresses require review. Conflicting identities, overlapping site networks, deleted assets, unavailable credentials and an address outside the intended site can also prevent transfer.

A possible address or site move waits for a second matching identity read at least two minutes later. The pending evidence window follows the shared polling interval: two intervals plus one minute for scheduling delays. At the five-minute setting, that window is eleven minutes. A newly received observation must still be fresh and newer than the previously accepted observation; repeating the same reading does not confirm a move. This also applies when equipment has a recorded address but no active tracking binding. Conflicting answering addresses keep the move for review.

Background tracking follows the shared polling interval and stops starting new reads when automatic polling is disabled. Fallback scans search the configured networks in bounded batches. A long queue can delay a device beyond the confirmation window, so the interval alone does not establish complete coverage.

Storage placement and removal are different workflows

A serial-confirmed observation at a site can move an eligible, uniquely matched asset from storage to that site and change its status to Deployed. Assigned or otherwise ineligible assets are not treated as available storage stock. This action records an audit event; check the resulting placement rather than assuming every location disagreement is corrected automatically.

Removing network equipment is a deliberate user action with its own confirmation and linked-asset effects. A component disappearing from discovery is not that deletion workflow. Inspect the confirmation before deleting equipment, and do not infer that connected neighboring devices should be removed with it.

Example: replacing a transceiver

Suppose serial A is installed in a switch port. A later supported read reports serial B in that same attachment. If B uniquely matches inventory, that asset becomes the current installation; otherwise Cenovel may create it after resolving the model. A remains an asset with its previous installation history. You still need to record whether A went into storage, repair or disposal.

If the later read instead reports a blank serial, Cenovel retains A's established identity and explains that the read did not confirm every installed part. If the inventory command failed, an empty result alone does not establish that A was physically removed.

If A was deliberately deleted from inventory, a partial read of an unrelated part must not make A appear again. When a later read actually reports A, its physical observation becomes visible, but its deleted inventory record remains deleted. Confirm the physical identity before using the separate restoration workflow.

Evidence and limits

Review the original observation time, the latest attempt state and the successful evidence for the particular class of information. A later page refresh or a successful port read does not make an older component inventory current. Older or conflicting component readings are prevented from replacing a newer installation.

Automated tests with simulated devices cover addition, repetition, replacement, removal, blank identity and selected conflict cases. Those tests do not prove every vendor command or a physical swap on every supported switch.

Limits of this guide
Physical component swaps have not been verified across every supported device model.
Discovery mapping tasks are a proposed workflow, not an available feature.
Some corrections described here, such as hiding deleted components after unrelated partial reads, may not be in your installed version. Check your release notes.

Sites, closets, stacks and port evidence
Navigate from a site to its closets and equipment, maintain a survey, and compare recorded connections with device observations without confusing missing evidence with a healthy or empty port.

Choose the right level of the record

A site gives location context. Its closets describe physical spaces and their surveys. Network equipment describes the managed device or stack, while the associated assets identify individual physical units. A port record describes a documented use or connection; an observation describes what a device reported. Start with the level relevant to the task rather than editing a convenient name elsewhere.

Before changing a closet, confirm the site, closet identifier, equipment name, management address and physical unit identifiers. Have the survey information or connection evidence available. Your account needs the applicable page and edit permissions, and department ownership can still make a visible record read-only. A working view does not establish that you may edit every device within it.

Give each site a type

Each top-level site has one site type, such as Elementary or Office. The type decides the group a site is listed under, how Analytics groups and filters sites, and whether outages at its sites are urgent. Child locations and storerooms have no site type.

An Administrator EX manages types in Settings › Locations › Site types. Each type has a name for one site and a group name for the heading its sites are listed under. Use Up and Down to set the order groups appear in. Renaming a type renames it everywhere it is shown; saved Analytics views keep following the same type after a rename.

Set a type's outage urgency to Normal or Priority. At a Priority type's sites, network outages are Critical and their alerts are marked URGENT. A Normal type's outages take the severity of the problem.

A type in use cannot simply be deleted. Choose the type its sites move to; the sites move and the type is deleted in one step. A new site saved without a type gets the type its name suggests; check it in the site's details.

To change several sites at once, select them in Settings › Locations and choose Set site type. The change is made in one step and recorded for each site that changed. If the selection includes a child location or a storeroom, nothing is changed.

Navigate from site context to the physical space

1. Open the relevant site and select Closets. Check the site context before choosing an Open closet link; similar closet identifiers can occur at different sites.
2. Review the closet identity and Recorded equipment summary. Read missing service counts as Not recorded, rather than as zero installed lines.
3. Use the Closet sections navigation to open Switches. Expand the relevant equipment with Show detail when you need its front panel or recorded detail.
4. From the site overview, use Inventory assets to reach the site's equipment register when you need the physical asset record rather than the closet survey.
5. If a closet photo is present, use Expand photo to examine it. Closing the photo returns you to the same location; a photograph is supporting context, not a current device reading.

Maintain a closet survey deliberately

Choose Edit closet and review Room and survey. The current fields include Status, Surveyed by, Survey date, Closet ID, Floor and Room / location. These describe the survey and physical space. Record who established the information and when. A later monitoring result does not automatically refresh the survey date or confirm every written note.

Lines patched in describes the service footprint counted at the switch. The screen explicitly distinguishes that from unpatched panel terminations. Keep unknown counts unknown until someone verifies them. The Recorded equipment summary separately presents switch units, recorded stacks, physical links, special ports and assigned UPS units; these are different measures and should not be added together as a device total.

Use Add network equipment only when the equipment is genuinely missing from the survey. Review Device / stack name, Management IP, Vendor, Model and Stack members before saving. Save changes, follow any presented confirmation, and reload the closet to verify the stored result. If another person changed the record, review the current version before reapplying your own correction. Do not repeatedly submit an old form over a conflict.

Read the model diagram as a model diagram

The physical panel is built from the identified chassis model and stack shape. A two-member model may draw many ports even when none has a documented connection. A count such as 0 of 96 recorded describes port records, not 96 successful network measurements. If the model cannot be identified, the panel may say there is no panel to draw.

Open More, then Model and diagram, to review the model used by the drawing. The review dialog can distinguish a physical stack member when more than one is present. Confirm the actual chassis identity before correcting the model; a port layout that looks familiar is not sufficient evidence. Records against reserved ports, ports the chassis does not have, or entries without port numbers are called out separately so they can be investigated rather than silently fitted into the drawing.

Inspect one port or compare several

1. Select a port on the panel. Its information stays in the Port information area after the pointer leaves the tile.
2. Use Control with another port selection to compare multiple ports. Each selected port has its own detail card and Clear control.
3. Use Front or Rear where the model provides those faces. Changing the face does not itself perform another device read or erase the selected port's details.
4. For keyboard use, focus a port and press Enter to select it. Press F2 to move focus to Selected port information.
5. Check the member identifier as well as the port name on a stack. Identically named stack ports on different members are different ports.

Separate records, readings and missing information

Descriptions, status, media, VLANs, PoE, optics, traffic and neighbours can come from different observations. A recent status sample does not make an older optical reading or neighbour observation current. Use each field's available evidence and time, and preserve unknown source information as unknown. Legacy data that cannot be attributed coherently must not be presented as one freshly verified snapshot.

An endpoint list is also evidence, not a complete physical inventory. A port with nothing listed may simply have no learned or retained endpoint information. Likewise, an optic observed by the chassis can exist without an asset record. Establish its identity before linking it to an existing physical asset.

Recorded | A documented connection or use. Compare it with observations before changing it.
Up, Down or Disabled | An observed state when evidence exists; inspect its timestamp and context.
Not read or an unknown value | The application has no usable reading for that field. It is not a down-state assertion.
Partial, failed or unsupported evidence | A collection limitation. Older successful fields may still remain available.
No port record | No documented port assignment; this does not establish that the port is unused.

Keep stack membership and history attached to the right unit

A stack position is not a permanent physical identity. Compare the member's asset or serial information when investigating a replacement. The port workspace clears selection when a member identity changes so that a previous member's selected detail is not carried onto the replacement. Ordinary survey edits that leave the identity unchanged can preserve selection.

Stack history uses membership periods to associate a unit's events with the stack. An event from before a member joined or after it left should not be treated as evidence about the current stack. When explaining a problem, record the site, closet, device, member identity, port and observation time together. This gives another operator enough context to distinguish a device replacement from a changed connection.

Handle failed loads and save conflicts

A failed stored-port request should report that the reading could not be loaded. It should not remain indefinitely labeled as a read in progress, and it is not evidence that the device is offline. Keep recorded details available while investigating the reading failure. Confirm the address and selected member before retrying.

If the closet model cannot hold recon fields or the structured network field is missing, resolve that setup issue with an administrator before expecting a survey to persist correctly. After a successful save, revisit the same closet and equipment to confirm it. These steps verify the record you changed; they do not claim a fresh network test or automatically reconcile every observation with the survey.

Limits of this guide
This guide is based on the application source and its tests; it is not a test of your installation.
A model diagram, a recorded survey and a device observation are separate evidence sources. Available detail depends on the model, permissions and retained readings.
Displayed fields were not necessarily collected at the same moment, and a missing observation does not prove absence.

Inventory, bulk editing and asset lifecycle
Create and maintain individual asset records, select a group safely, review bulk changes, and distinguish a move, a checkout and a deletion.

Start with the right record

The inventory register contains individual equipment records. A model describes the product; a serial identifies the physical item; an asset tag records your organization's label. A site or closet describes placement, while a checkout describes custody. Changing one does not establish the others.

Search before creating. Check the existing serial and the Recently deleted list if hardware has returned to service. Discovery, manual entry and spreadsheet import should converge on the same physical record rather than produce a new asset for each way it was entered.

Create or correct an asset

When correcting an existing record, resolve a conflicting serial instead of assigning it to a second asset. The editor checks for concurrent changes; reload and compare another person's saved work before submitting a replacement draft. A successful form submission is not evidence that an external device now reports the same values.

1. Open New asset with an account permitted to create records in the relevant inventory area. A catalog model must exist before the form can be submitted.
2. Enter the serial and review any match warning. An existing live match offers its record; a deleted match directs you to restoration rather than creating another item with that serial.
3. Record the asset tag and name when known. A blank physical tag is displayed as N/A; do not invent a label merely to fill the field.
4. Choose the model, status and site or closet. The vendor control narrows model choices. Status affects the available placement choices, so check the destination again after changing status.
5. Review the selected model's fields before entering network, funding or other specialized details. If the model lacks the necessary fieldset, the warning explains which information cannot be saved with it.
6. Save, reopen the asset and check the recorded values. If a restored draft appears after a session interruption, it is still unsaved until you explicitly save it.

Select the intended rows

Use the row checkboxes to select individual assets. Select an anchor, then Shift-click another row to include the intervening range. Ctrl-click or Command-click a row toggles selection without opening it. A normal row link opens the asset, so distinguish inspecting a record from selecting it for an action.

Before Edit selected, check the count and asset names in the preview. The Delete confirmation shows only the number selected, so check your selection in the list first. Filters, ordering and pagination change the context in which you are choosing records. Do not assume that selecting visible rows means every matching asset in the estate is selected. Bulk editing accepts at most 200 records in one reviewed selection.

Preview a contextual bulk edit

1. Choose Edit selected. Leave fields unchanged unless this operation is intended to modify them.
2. Choose shared placement, model or funding changes where applicable. Changing the model also changes the category and which custom fields the assets can store.
3. Use Add a field for additional supported values. Custom fields appear only when every selected model, or the replacement model you chose, supports them. Split a mixed selection when different models require different changes.
4. Enter identifiers separately for each asset. Serial, asset tag, MAC address and supported management-address identifiers are individual values, not a single value to copy across the whole selection.
5. For eligible ordinary fields, use Clear this field to deliberately erase the value. Leaving the input empty means leave unchanged. Remove field excludes that proposed change.
6. Choose Preview changes and read the changing and refused groups. Review the count covered by the confirmation even when the table shows only its first 60 rows. Apply only after the selection and changes match your intention.
7. Read the result counts, then revisit the records. Closing the drawer after application starts does not cancel the running operation.

Illustration: Actual isolated desktop bulk edit. Entering Notes proposes that value for the selected assets; Clear this field deliberately erases it, while Remove field excludes the change. The test saved Notes and confirmed existing serials were unchanged.

Interpret partial and uncertain results

A bulk operation is not an all-or-nothing promise across the selection. For example, if two assets save and a third fails, retrying must preserve those two results. Reusing the original retry with a different selection or different values is refused; it needs a new preview. Keep the distinction between a known failure and an unanswered save request.

Updated | The operation reports a saved change for that record. Check the result and relevant asset details.
Already applied | The original request already saved this record. The retry confirms that result without rewriting it or overwriting later changes.
Would be refused | Read the reason given. Reasons include permissions, another department's ownership, custody, another editor, a field the model cannot store, no actual change, a closet record, or a record no longer in the inventory.
Failed | Some other records may already have saved. Resolve the reported problem, reload and preview the remaining work.
Needs review | A saved outcome could not be confirmed for this record. Inspect current data and create a new reviewed preview; do not assume nothing changed.
Records changed after your preview | Nothing is applied. Cenovel shows the updated list; review it and confirm again.

Move equipment or transfer custody deliberately

Use Move to record a new site or closet and an explanatory note. Reopen the record and register to confirm the placement. A supported action may offer Undo; use the actual result and history rather than assuming every later change can be reversed without conflict.

Check out records who or what has the asset. For a person checkout, the confirmation includes acknowledgment that the person has collected it. Do not confirm collection before the physical handoff. A checkout can restrict later editing while the equipment is held in custody. Returning equipment and changing its physical placement are related decisions, but are not interchangeable facts.

Replace a failed unit in place

Use Replace on the asset page of a unit fitted in a switch position, a stack member slot or a part bay. The position keeps its name, management address, ports and links; only the physical unit changes. The unit that leaves keeps its own record and history.

After a replacement, the asset page can ask you to confirm the new unit's identity. Reachability checks after the work wait until someone chooses Confirm identity. If a read finds a different serial in a position without a recorded replacement, the asset page shows A different unit answers here. Choose Confirm replacement to open Replace with the details filled in, or Not a replacement with a reason.

1. Choose where the new unit comes from: a spare from storage, or enter or scan its serial and choose its model from the catalog. If a record in storage already has that serial, that record is used.
2. Choose what happens to the old unit: Spare in a storeroom, RMA to the vendor or Disposal. It cannot stay deployed. RMA opens a vendor case and puts the unit on the RMA board. Disposing of an E-Rate funded unit needs a reason and your confirmation that its E-Rate disposal rules are met.
3. Choose Replace. The result says where the old unit went and what changed. Its open outages close as replaced; that records the swap, not a repair of the old unit.

- A serial already on another live record is refused; one device keeps one record. A serial that belongs to a deleted record is refused too: restore that record if it is the same unit.
- A different model of the same kind needs your confirmation. A different kind of equipment is refused. A unit checked out to someone must be checked in first.
- If the unit changed while the dialog was open, Replace is refused and nothing is changed. Any failure part-way leaves nothing changed.

Delete and restore with the record's history in mind

Deletion removes an asset from the active register and ordinary search. The confirmation identifies the record or selected count. Deleting a single asset gives you ten seconds to cancel. Bulk Delete has no cancel window; recover those records from Recently deleted. Recently deleted keeps an ordinary deleted record restorable for the period set in Settings › Deployment under Data retention (Keep deleted records restorable for; 30 days unless changed), then removes it for good.

A record with recorded funding, an E-Rate plan link or FRN, funding in its change history, or disposal, replacement or RMA history is never removed for good. It can still be deleted and restored at any time. Its Kept column in Recently deleted, and Keep record until on the asset page, give a keep-until date and its basis: for E-Rate equipment, 10 years after the purchase date; for grant-funded equipment, 3 years after disposal; the later date wins. When the date it depends on is not recorded, the record says so and is kept with no end date. Cenovel does not remove a held record when that date passes; the date tells you how long the record must be kept.

Open Recently deleted from the inventory menu, find the exact record and choose Restore when permitted. The server checks the deletion being restored, page permissions and department ownership. If someone restored or deleted it again while your list was open, refresh instead of assuming your stale action succeeded.

Removing network equipment has a separate confirmation and can affect its linked member assets. Review that impact before saving the removal. Discovery reporting a missing component is different: the installation may change while the former asset remains. Disposing of funded equipment also requires its own lifecycle and evidence review; ordinary deletion is not proof of disposal.

Verify one useful result, not just a success message

After a change, check the intended value and one value that should have stayed unchanged. For a notes-only bulk edit, for example, reopen a changed asset, check its note and serial, and confirm an unselected asset was unaffected. For a move, check both the asset drawer and its location in the register.

Record the exact error and affected selection when a workflow stops. A fresh page may show work that committed before the connection failed. Resolve that evidence before repeating an operation that creates, moves or deletes records.

Limits of this guide
The bulk-edit field list is explicit; it does not promise support for every custom field.
Storage batch and kiosk work is not yet an available workflow.
This guide describes the current development release and may include fixes that are not in your installed version.

Outages, evidence and planned maintenance
Understand what each outage detector observes, what can confirm recovery, and how planned work and management-network uncertainty affect alerts and history.

Read an outage as an evidence-based finding

Cenovel records conditions it can observe through network management and server management controllers. An outage may identify lost contact, a missing stack member, a failed part or a capacity risk. These are useful operational signals, but they do not all mean users have lost service. A responding switch does not prove that traffic is forwarding, and a responding server controller does not prove that the operating system or an application is healthy.

Check the cause, affected device or part, observation time and supporting detail before deciding the response. Critical and Warning are triage priorities. They are not measurements of how many people are affected. Whether a site is a priority site comes from its site type, not from its name or notes. In Settings › Locations › Site types, an Administrator EX sets each type's outage urgency to Normal or Priority. A network outage that monitoring opens at a site whose type is Priority is raised to Critical, its alert is marked URGENT, and the alert names the site type as a priority facility.

Prepare the record and the management read

- Record equipment at the correct site and closet, with a usable management address. Keep stack membership and access-point connections accurate: several detectors compare current evidence with those records.
- Configure the applicable credential, trusted SSH key or server certificate, and permitted management networks. A successful login does not guarantee that every hardware table or command is supported or complete.
- Network lost-contact detection requires a successful monitoring baseline. Cenovel reports a switch as not answering only after it has read that switch successfully at least once; a retained discovery identity alone is insufficient. Server-controller lost-contact detection does not have that same prior-answer requirement.
- Viewing current outages, viewing history and downloading evidence are separately permissioned. Scheduling, editing or canceling maintenance requires current-outage edit permission and permission to write.

Network detectors

The following are the implemented causes and their default priorities. A single eligible assessment can open a condition; there is no common requirement for three failed checks or another fixed failure count. A detector runs only when the read supplies the evidence it needs.

Switch not answering Cenovel · Critical | A previously observed switch stops answering with a failure classified as transport silence, such as timeout or no route. | A successful system read can clear it. Credential or trust problems do not establish network recovery. This identifies lost management contact, not its physical cause.
Stack member missing · Critical | A complete membership reading disagrees with the recorded roster. Where only counts are usable, the reported positive count is lower than the recorded count. Serial-only ambiguity is reported without naming an arbitrary missing member. | A complete, sufficiently identifiable roster must account for the member. Keep replacements and renumbering accurate in the record; an incomplete roster cannot clear the incident.
Power supply failed · Warning | A read identifies a failed supply. A supply the device reports as disabled counts as failed; testing, unknown or missing states count as not reported. Supported environmental output can also identify a failed supply. | Recovery needs a complete reading that shows the original identified supply healthy again. Omitted, unrelated, unknown or duplicate supplies cannot establish recovery. Management contact alone does not prove forwarding or redundancy.
Access point not answering Cenovel · Warning | A previously observed access point stops answering. A known upstream switch or stack/uplink incident may explain it and group it under that incident instead of opening another standalone outage. | A successful access-point system read can clear it. An answering upstream switch narrows the investigation but does not prove the access point itself is the root cause.
Uplink down · Critical | Complete interface and neighbour readings show a previously recorded neighbour missing from its local port, with that port administratively up and operationally down. | Every originally lost port remains a recovery obligation, even if later neighbour snapshots omit it or another port fails. Complete interface and neighbour readings must uniquely identify each port with known states and show it up, administratively disabled, or with a neighbour. Clearing does not prove restored forwarding. Malformed original evidence blocks automatic recovery.
Mist reports this device disconnected · Warning | A Juniper Mist read reports a linked device on a mapped Mist site as disconnected from the Mist cloud. A device with no status from Mist, an unlinked device or an unmapped site concludes nothing, and a failed Mist read opens nothing. | A later Mist read reporting the device connected closes it. This is Mist's report, not Cenovel's own reachability check; see the Juniper Mist guide.
Switch restarted · Warning | A supported uptime read reports a positive value lower than the previous positive value. | A subsequent complete uptime assessment without another decrease can clear it. Treat this as restart evidence, not a proven reboot cause; the detector does not independently exclude counter wrap.
Cooling failed · Warning | An environmental reading reports a fan in a recognized failure state, including failed, fault, critical, stopped, off, down or degraded. Unknown and absent are not failure states by themselves. | A complete environmental reading must positively identify the previously affected fan as healthy. Missing or renamed fan evidence can leave recovery unconfirmed.
PoE budget exhausted · Warning | Allocated power reaches or exceeds reported capacity, or a port reports power-deny, denied, faulty or faulted. Member-specific budgets are used when available. The separate low-headroom indicator begins at 85%; that alone does not open this outage. | Recovery needs complete usable budget evidence below exhaustion and known non-denied states for previously affected ports. Spare capacity on another stack member is not assumed transferable.
PoE will not survive a supply failure · Warning | At least two supplies are listed, some but not all are healthy, and allocated power exceeds estimated surviving capacity. The estimate divides total capacity equally between listed supplies. | Complete PoE and supply evidence must no longer meet the rule. Unequal supplies, power-sharing modes and vendor reserve policies can invalidate the estimate; it is a resilience warning, not proof of current or inevitable loss of service.

Server-controller detectors

These five causes use supported Redfish hardware readings. Controller health describes hardware and reported conditions. It does not test a hosted application, user login or operating-system service.

Server not answering Cenovel · Critical | The controller read returns a not-answering outcome. This can include transport failures and other errors that prevent a usable controller read. | A successful controller answer or explicit credential refusal clears lost-contact status. No credential or an unaccepted changed certificate does not clear it. Read the failure detail before concluding the server is powered off.
Server power supply problem · Warning | A supply reports failed or degraded health, including supported vendor configuration problems. Lost redundancy also qualifies when at least two supplies are installed and no individual failed supply already explains it. | The same identified supply must be read in a recognized non-failing state, or the redundancy group must report redundant. An explicitly absent supply can close its fault incident; that does not mean a replacement was installed.
Server fan failed · Warning | An installed fan reports Redfish Warning or Critical health. A speed reading alone is not the failure threshold. | The same identified fan must report OK or explicitly absent. A fan omitted from a partial collection is not confirmed recovered.
Server too hot · Critical | A sensor reports Critical health, or its value reaches or exceeds its reported upper critical or fatal threshold. There is no universal temperature in degrees used for every server. | The same sensor must provide a recognized non-critical reading. Warning can clear the critical incident while still contributing a hardware warning.
Server hardware warning · Warning | Read storage health is non-OK, a read temperature reaches a caution condition, or overall health is non-OK and non-unknown without a more specific part failure explaining it. | Clearing requires complete healthy system, storage and temperature evidence. A healthy system summary alone cannot clear an earlier warning when supporting collections are unread or capped.

Review and confirm recovery

For example, a switch may answer while its fan command fails. Its lost-contact incident can resolve while its earlier fan incident remains open. Similarly, a controller may return three healthy fans and fail to read the fourth: the missing fourth fan is not automatically declared repaired.

Incident times are detection and confirmation times, not exact physical failure times. Outage duration excludes time held for management-network uncertainty. Site downtime merges overlapping incident periods instead of adding every device's minutes as if they were separate periods of site-wide disruption; it still does not measure actual user impact.

When a fresh successful read clears a switch or access-point lost-contact incident, its recovery entry can include the complete current uptime value and its source. The entry keeps a physical restart verdict unknown. A short uptime alone does not prove a reboot; a long uptime does not prove that only the network path failed. Stored fallback readings and unrelated hardware recoveries do not receive this contact-recovery annotation.

1. Open the incident detail and compare the named device, member or part with the site record. Inspect the underlying failure and latest evidence rather than relying on the title alone.
2. Check whether the required portion of the read completed. Positive fault evidence can still be useful in a partial read; missing data cannot be treated as a healthy replacement for an earlier fault.
3. Check reported user impact separately. For an uplink incident, confirm the traffic path and redundancy. For a server incident, check the application through its normal service checks.
4. After repair, obtain the relevant supported reading and verify the incident's recovery entry. A general successful connection is insufficient for an unread failed fan, supply or storage condition.
5. Use history and available evidence downloads to preserve the timeline. If equipment was removed from Cenovel, distinguish the subject-removed closure from restored service. When a unit is swapped out with Replace, the old unit's open outages close as Replaced by the new serial on that date; for a stack member, only that member's outages close. That records the swap, not a repair of the old unit.

When Cenovel may have lost its own management path

Cenovel raises a management-network condition when at least two distinct addresses have transport-silence evidence across the current check and the recent 15-minute window, at least one was silent in the current check, and no genuine answer appears in either set. The failures need not all have occurred at exactly the same instant.

A successful read or explicit sign-in refusal counts as an answer for this condition. A changed key, certificate response, closed port or negotiation failure is treated as ambiguous for deciding whether the wider management path recovered. One isolated silent address cannot establish this shared condition.

While the condition is open, new switch and access-point lost-contact outages are withheld. Existing incidents of those two kinds are neither confirmed nor resolved, and their duration clocks pause. Hardware and server-controller incidents are outside this particular hold. A genuine answer releases the hold; a return within 15 minutes can remain the same management-network episode.

If Cenovel could not use its own stored credential and therefore never contacted a device, it reports a separate console-credential problem. Correct access through Monitoring rather than treating this as evidence that the device failed.

Schedule maintenance and keep the history

Maintenance suppresses alerts while monitoring continues and incidents remain recorded. Covered outages are excluded from ordinary current-outage lists, Today, actionable incident summaries, morning-report incident sections and ordinary outage totals. Moving an incident into maintenance is not reported as a recovery. The site's outage list retains covered records with maintenance context, while its outage statistics exclude them.

An incident still open when coverage ends becomes eligible for ordinary visibility and alerts again. An incident resolved while covered retains its maintenance classification in history. Ordinary evidence exports exclude maintenance incidents, so a site's visible history and an ordinary export can contain different rows. Maintenance is not a promise that a fault was repaired or that all of its duration will be subtracted from a later unsuppressed incident.

Scope matters. A site window covers everything monitored at that site, including devices added during the window. A closet window covers the switches and servers in that closet and the access points behind those switches; other closets at the same site still alert. A switch window covers that switch or stack, not access points behind it that fail on their own. An access-point window covers only that access point. A server or address window covers the device at that address. An access point that Juniper Mist reports is offered as Juniper Mist's disconnected report, and its window quiets that report. Ended and canceled windows cannot be edited.

A future window quiets nothing until it starts. When a window ends or is canceled while an outage it covered is still open, the outage returns to Outages and its alert is sent once, even if several parts of Cenovel notice the end. That includes an alert that was waiting to be sent when the window began. An alert already delivered before the window is not sent again, and an outage that cleared during the window sends nothing.

1. Choose what the work affects. Only things Cenovel monitors are offered, each once: a site, a closet, a switch or stack, an access point, a server, or a polled address. Inventory records without a management address raise no alerts, so they are not listed. Read the line under the choice: it says what the window will quiet and what will still alert.
2. Enter a readable reason, start and end times, and the intended time zone. Add a work reference when useful. The end must follow the start, and a single window cannot exceed 180 days.
3. Confirm the scheduled window before starting work. It becomes active at its start time and stops applying at its end time. Edit or cancel a current window when plans change; cancellation requires a reason.
4. Use the site's outage history to review incidents observed during the work. After maintenance ends, inspect any still-open conditions and obtain recovery evidence.

Interpret protocol evidence conservatively

The official Interfaces MIB describes an interface's operational state, not an end-to-end application's availability. Missing neighbour advertisements can also reflect the neighbour protocol or its configuration. Cenovel therefore combines a recorded neighbour, complete reads and a down operational port for its uplink rule.

SNMP system uptime measures time since the management portion was initialized. Its TimeTicks representation wraps after approximately 497 days. A decrease can suggest a management-agent restart or a wrap rather than a whole-device reboot. Corroborate the event with device logs when the distinction matters.

The ENTITY state standard allows enabled to mean partially or fully operable; it does not prove redundant power. Redfish likewise distinguishes a component's health from the health of the containing system. A failed redundant supply can need attention while the system continues operating. Use the vendor's reported detail and actual service checks to establish impact.

RFC 2863: The Interfaces Group MIB: https://www.rfc-editor.org/rfc/rfc2863.html
RFC 3418: SNMP system uptime: https://www.rfc-editor.org/rfc/rfc3418.html
RFC 2578 section 7.1.8: TimeTicks: https://www.rfc-editor.org/rfc/rfc2578.html#section-7.1.8
RFC 4268: Entity State MIB: https://www.rfc-editor.org/rfc/rfc4268.html
DMTF Redfish Data Model Specification 2025.2: Status and HealthRollup: https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2025.2.pdf
Limits of this guide
This guide is based on the application source, automated checks and the linked protocol references. It does not claim validation against live production devices.
Which detectors can run depends on supported commands, tables, controller resources and a trustworthy inventory baseline. A successful management connection does not mean every detector ran.
There is no universal consecutive-failure threshold, recovery delay or user-editable threshold. Protocol retries are not an incident debounce policy.
Some incident summaries state forwarding loss, downstream loss, restarts or future PoE impact more firmly than the evidence supports. This guide separates those inferences from what was observed.
The PoE redundancy calculation assumes the listed supplies have equal capacity; it does not model vendor-specific power sharing.
Server-controller reads use the first system and chassis and limit how much they collect. Failed, capped or paged collections cannot be assumed complete.
Server not answering Cenovel can mean a usable controller read failed, not only that the network was silent. Server-controller incidents are not held by the switch and access-point management-network condition.
Maintenance coverage follows the incident's recorded scope and location. An access-point window covers only that access point's own incidents; use the server's own entry, its address, its closet or its site to cover a server-controller incident.
Maintenance flags mark covered incidents; they do not subtract every maintenance overlap from every incident duration. Site history keeps planned records, while ordinary outage exports leave them out.
The Switch restarted detector relies on a drop in reported uptime and needs further validation.
If the original uplink-recovery evidence is malformed, Cenovel will not close the incident automatically even after healthy readings. That state needs evidence repair or administrative removal; it does not confirm a continuing physical fault.
The correction that leaves an address unmonitored until a first successful manual SSH read may not be in your installed version.

Notifications, delivery and morning reports
Use the account feed, understand separate delivery-channel rules, review stored morning reports, and apply maintenance suppression without mistaking silence for recovery.

Distinguish the feed from external delivery

The Notifications panel combines applicable console notices with selected activity history. Its Feed is a view of information available to your account. Preferences decide which of those items you see here. Email and webhook delivery are separate: administrators configure channels with their own families, severity floor and quiet hours. Hiding a family in your panel does not turn off its delivery channel.

The morning report is another distinct workflow. It is written and stored on its schedule, and can optionally be emailed to selected people. A report can exist without an email being sent. Conversely, receiving a notice does not mean the corresponding underlying issue has been resolved. Open the relevant record and inspect its present state.

Review and filter the account feed

1. Open the header's notification or activity control to show the Notifications panel, then choose Feed.
2. Use Search notifications and Filter notification type to narrow what is displayed. Increase the selected Last count when you need a wider loaded history.
3. Read the title, message, actor and time before following a notice to its source. Check that the destination is the record you intend to investigate.
4. Use Mark all read only when you intend to advance your read position for the loaded activity and console notices. It is broader than marking only the rows remaining after a local search filter.
5. If the panel says No matching notifications, clear search and type filters and review Preferences before concluding that no activity exists.

Save preferences for this account

Open Preferences and review Notify me about. Current families include Outages & recoveries, Physical & topology, Equipment relocations, UPS service & health, Lifecycle, Projects & tasks, Assignments & checkouts, Stock & reorder and General inventory changes. The descriptions help distinguish operational alerts from routine changes. Choose the families relevant to your responsibilities rather than treating every inventory edit as an incident.

Under In this panel, Show notifications here controls the panel display and Minimum severity filters lower-priority notices. Choose Save preferences to persist the choices. A save failure leaves the outcome unresolved; reload and check the stored preferences before assuming your next session will use the edited values.

Where the test-notification action is available, it creates an informational notice in Stock & reorder. The application explains when that test is hidden because the panel is off, the family is muted or the minimum severity excludes Info. This checks notice creation and account filtering. Any delivery channel that subscribes to Stock & reorder at Info will also email or post the test notice; that still does not confirm the channel works.

Ask an administrator to inspect the delivery channel

For missing external alerts, supply the notification, expected channel and approximate time. An administrator should inspect whether the channel is enabled, subscribes to the notification family and accepts its severity. Quiet hours can defer delivery in the channel's configured time zone; Critical notices skip quiet hours unless the channel sets a different bypass severity. Your account's panel filters do not explain these channel decisions.

Channel management requires structural administrator authority and the appropriate notification-settings page action. The console has no screen for delivery channels. An administrator with notification-settings access manages channels, their delivery history, health and tests through Cenovel's API.

A channel test is a real delivery to its configured destination. Confirm the recipient or endpoint and the purpose before sending it. A successful test confirms that particular attempt; it does not establish that every notification family is subscribed or that every future message will be delivered.

Interpret delivery outcomes carefully

Retryable failures use bounded retries and delays; permanent failures or exhausted attempts can be abandoned. Preserve the failure summary when escalating. Do not repeatedly create new test notices to compensate for a broken channel. Missing secret configuration or an unavailable service can prevent delivery even when the original notice remains visible in the console. Channel changes and tests are recorded in the audit log.

Queued | Delivery remains pending. Check the next attempt and quiet-hours settings.
Queued (held) | The attempt is waiting because of a setup fault, such as missing configuration. Inspect the recorded reason.
Sending | An attempt is in progress.
Failed | The attempt failed; inspect whether a later retry is scheduled.
Abandoned | Delivery will not continue through that attempt's retry path. Resolve the recorded cause.
Sent | The transport accepted the attempt. This does not prove that a person read it.

Understand saved reports and permission changes

A scheduled saved report is computed with the named person’s current access. Copies sent to an outside address or a notification channel use the schedule owner’s access and require that owner to retain Administrator EX authority. The stored copy keeps its original contents; a later retry does not rerun the query against newer data.

Before each delivery attempt, Cenovel checks whether the original report’s data scope is still permitted, whether the intended person or destination is still selected, and whether an included attachment is still permitted for download. A department change, removed recipient, changed email address or revoked access can cause the retained copy to be abandoned. Correct the access or recipient settings, then generate a new report if appropriate; an old copy is not redirected to a new address.

Morning reports with saved-view sections retain the original permission evidence for every included section. Losing access to one included section stops that entire retained copy from being delivered. Editing the current saved view does not change which permissions the older copy needs.

After upgrading to a release with these permission checks, previously queued saved-report copies without original permission evidence cannot be sent. Their retained contents are preserved until normal retention removes them. A newly generated report records the evidence needed for delivery.

Read and share a stored morning report

1. Open Outages, then Morning report. Check the report day and generation context instead of assuming the latest available report is today's.
2. Use Choose a day and Open report to revisit a stored report. A day without a report is reported explicitly; it is not replaced with another day's content.
3. Read coverage alongside outages and recoveries. Incomplete monitoring coverage is a reason to qualify the report, not a reason to describe the estate as fully checked.
4. Use Copy email text when you need to paste the stored report into a message. If browser copying is blocked, use the Text download where your permissions allow it.
5. Use Text or PDF for an export when Download is allowed. Keep the report day with the exported or copied content.

Configure report timing and email separately

Administrator EX can change the district morning report when the required report-page permissions are present. Its settings show Schedule, Report and email, the displayed time zone and the next-report status. Set Write the report at in the shown zone. Enable Email the report when it is written only when you have chosen the intended recipients.

People without an email address cannot be selected; correct their address under People first. Enabling email with nobody selected prevents saving. Review the Signature because it is used in the email, copied text and exports. Save and revisit the settings. If no mail server is configured, the report can still be written; email requires the mail configuration identified by Settings › Deployment › Mail.

A message that today's report was due but has not been written calls for checking the console worker and report configuration. The current application retains morning reports for 365 days. An old report removed by retention, a future day and a day never generated are different conditions.

Suppress planned maintenance without erasing evidence

Use Schedule maintenance for a monitored site, closet, switch, access point, server or address, and read what the drawer says the choice will quiet. Record Starts, Ends and the reason for suppressing alerts. The end must follow the start. A maintenance window is a planned coverage decision, not a declaration that the device is healthy.

Covered outages remain identifiable as Maintenance in site history, while the relevant alert, incident and morning-report views exclude them. Observations remain available. This distinction prevents planned work from appearing as an unplanned outage without rewriting the underlying evidence or presenting suppression as recovery.

If work finishes early, use Cancel on the window in Maintenance coverage and provide the Cancellation reason. Review the resulting outage view: an issue still open becomes visible again and its alert is sent once. Canceling maintenance does not repair equipment. Confirm the restored alerting context separately from the physical work and retain the reason for changing coverage.

Limits of this guide
Email transport was simulated in testing; no claim is made about delivery through any particular email provider.
Channels are managed and tested through the API. No dedicated channel-management screen is described.
Personal feed filtering, channel delivery, report generation and maintenance suppression are separate mechanisms; success in one does not prove the others.
The permission checks on saved-report delivery may not be in your installed version. Check your release notes.

E-Rate funding and equipment lifecycle
Record a funding cycle, connect site plans to identifiable equipment, review attribution and movement, and export the evidence currently held in Cenovel.

Start with the record you need to maintain

Use E-Rate to connect a funding cycle, its participating sites and the equipment recorded against it. Cycles describe the program; Sites holds the planned changes; Funded Inventory follows individual assets; Documents holds supporting references. These records answer different questions. A cycle marked active does not prove that its equipment has arrived, and an installed asset does not prove that every funding milestone has been completed.

Before editing, gather the cycle name, confirmed funding year, participating sites, known milestone dates and the records supporting them. For equipment, have the asset tag or serial, catalog model, funding source, funding request number, purchase reference and installation date. Your account needs the relevant page permission; creating or changing plan structure also requires structural authority. Downloading evidence is a separate permission.

Create and revisit a cycle

1. Open E-Rate, then Cycles, and choose New cycle. Enter its required name and a scope that explains the intended work.
2. Record the funding year and the start and end dates that describe this cycle. Read the displayed funding-year label carefully: Cenovel distinguishes the funding year from the district fiscal year.
3. Choose the participating sites, add program notes, and enter only milestone dates supported by your records. Leave dates blank when they have not been confirmed.
4. Create the cycle and review its saved record. Open Edit cycle to correct it, then reload to confirm that the saved dates, notes and site membership are the intended ones.
5. Use Open in Sites from the cycle record to review the sites within that cycle. Check the active cycle filter before changing a site plan.

Import a cycle schedule deliberately

Choose whether the file creates a new cycle or replaces the schedule of an existing cycle. To update a cycle, select that existing record; a new-cycle import with a name already in use is refused rather than silently changing it. Review which sites will remain and which will be removed before applying the file.

An import uses the permissions for the changes it makes. Creating a cycle does not grant permission to edit an existing one. Schedule additions, updates and removals require their corresponding permissions. An import that is refused for a missing permission leaves the cycle and schedule unchanged. Administrator EX retains its full access.

If the import is refused, keep the file and review the reported permission or conflict. Reload the current cycle before correcting a stale version. Do not interpret a failed response as a successful schedule update; reopen the cycle and verify the saved membership and dates.

Treat milestones as recorded evidence

The milestone fields include Form 470 posted, Form 471 certified, FCDL received, Form 486 filed, Service delivery deadline, Invoice filed and Invoice deadline. The cycle form will not save an end date before the start date, and Form 471, FCDL and Form 486 dates cannot come before the step before them. Correct the offending field in the existing form; validation should leave your other entries available.

A calendar message saying Deadline not confirmed is an information gap. Record a confirmed invoice deadline when available; the calendar then identifies it as a Recorded deadline. Clearing that field restores the unconfirmed state. Do not replace missing evidence with a convenient estimate or interpret a received-letter date as another date the letter may contain. Cenovel records and displays your information; it does not certify eligibility, filing acceptance or regulatory compliance.

Build site plans without confusing plans with stock

Within Sites, select the cycle and site before working on its plan. Plan categories include Access points, Switches, UPS, Cabling and Other. Decisions are Keep, Replace, Add or Remove. Stages run from Undecided through Planned, Ready and Installing to Accepted. Use these stages to describe the work actually reviewed; they are not a substitute for recording the corresponding physical equipment.

A planned model and quantity describe an intention. Linked units identify the assets used to satisfy it. Review existing deployed equipment and any recorded closet information before adding replacements, so that a typed count is not mistaken for another physical device. Editing plan structure and linking units have distinct server checks. If unit details are unavailable, confirm access to the equipment page before concluding that the plan has no equipment.

A record may refuse removal because plan lines still reference it. Review and resolve those relationships through the plan workflow rather than trying to delete the parent repeatedly. When another person has changed a plan, reload and review the latest state before submitting a correction.

Understand which equipment counts as funded

Funded Inventory includes an asset when its funding source is E-Rate or it has a live received-unit link to a site plan. A year label alone, an intended replacement target, or an unlinked historical unit record does not establish that connection. A linked unit identifies recorded delivery against a plan; it is not independent proof of eligibility or approval.

The verified export correction applies that same qualification, then selects the chosen year from the asset or its historical attribution. If those years disagree, the asset can appear in either relevant year and the disagreement remains visible. Qualifying equipment with neither year appears in No year recorded. The current plan cycle year is not substituted: moving a site plan can change its cycle without changing the original purchase record.

Automatic relocation capture is limited to qualifying equipment and preserves existing attribution. Older automatically captured attribution may have been based only on a year label; inspect its note and supporting records. Historical attribution remains available even when the asset does not currently qualify for Funded Inventory.

Keep asset identity and funding attribution together

In Funded Inventory, review the funded site alongside the current location. Attribution requires a school that still exists and can include the funding year and a note. A difference between funded site and current location is a review signal, not proof of an improper move. Examine the movement and supporting decision before changing attribution. Changing the funded site merely to remove a warning can erase the distinction you needed to investigate.

Attribution changes apply the asset’s page edit permission, department ownership and active editor protections in addition to Funded Inventory edit permission. Administrator EX retains cross-department access. A missing asset is rejected.

Asset tag and serial | The identifiers belong to this physical unit, not merely another device with the same name.
Funding source and year | The values describe the intended funding record; an ambiguous year label needs correction.
Installed on, FRN and purchase reference | These fields are populated from supporting records. An installation date is not a purchase date.
Funded site and current location | The school whose allocation paid for the unit is recorded separately from where it stands now.

Follow movement and disposal through the asset record

Before moving or disposing of funded equipment, review its funding record and the conditions in your authoritative documents. Preserve the physical identity, original attribution and the reason for the lifecycle action. Some closet relocation paths capture missing attribution from the equipment's existing site; review that automatically recorded information instead of assuming it replaces a funding decision.

Record disposal through the asset's disposal fields and workflow. The evidence pack reads the recorded disposal date and note, along with current status and location. A move, status change or retirement does not by itself establish that an external requirement has been satisfied. Missing dates remain missing evidence; do not backfill them from the date you happen to perform the review.

When a funded unit is swapped out with Replace and sent to disposal, Cenovel asks for the reason and your confirmation that its E-Rate disposal rules are met before it records the disposal.

Export and check an evidence pack

The workbook states that it covers records this account may export. Restricted records and documents are omitted from the workbook and its counts; an empty permitted result is not proof that the district has no records.

The exceptions sheet includes an away-from-funded-site row only when that asset is selected in the funded register for the workbook. A blank or different historical attribution year no longer hides that selected moved asset. Unknown current placement cannot establish that equipment is away.

The workbook also lists Replaced units: each swap recorded with Replace, what happened to the old unit (spare, RMA or disposal) and the unit that took its place. Deleted funded units lists funded records that were deleted. Such a record is never removed for good; its Retained until date and basis say how long it must be kept, and a blank date comes with the reason it cannot be worked out.

1. Choose a funding year and export the E-Rate evidence workbook with an account allowed to download Funded Inventory. The verified permission correction also requires view and download access to each asset’s owning page; document references require both permissions on Documents.
2. Review the Summary, funded assets, equipment away from its funded site, equipment marked E-Rate without a year, and supporting document references.
3. Investigate missing installation dates, FRNs and purchase references. Compare the asset year with its attribution year when the workbook flags a disagreement.
4. Check the generation time, pack digest and reported audit-chain status. Keep the exported file with the records for the review it supported; its digest helps match that particular export to its audit entry.
5. Correct the underlying records and export again when needed. Retain the distinction between the earlier export and the corrected one.

Access checks and concurrent changes

The following checks may not be in your installed version. Unit matching follows the same inventory visibility rules as the register. A restricted asset produces the same unknown-asset result as a missing one. Site-plan asset details also respect these rules, while the plan totals remain available through rollout access. Administrator EX retains full access.

Before assigning a tag, Cenovel rechecks the device serial, current department and existing tag when the save can proceed. If another person changes those details while your save is waiting, the assignment is refused. Refresh the preview and review the current record before trying again; an earlier preview is not permission to overwrite a later change.

Funding attribution saves recheck access after locking the asset against concurrent changes. The attribution and its audit record are saved together. A refused save leaves the attribution unchanged. Review the response, reload the record and resolve the reported permission or editing conflict before retrying.

Keep records for the applicable period

USAC distinguishes equipment inventory records from broader program documentation. Its equipment guidance calls for an updated asset register for ten years after purchase. General E-Rate documentation is retained for at least ten years from whichever is later: the funding year’s final day or the funding request’s service delivery deadline.

These dates can differ. Keep an export with its supporting funding records, and check the current USAC guidance and your organization’s requirements before removing evidence. An application deletion or a successful workbook download does not determine when records may be destroyed.

Handle gaps without overstating the result

An empty export for a quiet year can be a valid result. It does not prove that no equipment was funded: the pack reflects the records Cenovel can select, and deleted assets are excluded from its funded-asset query. A broken audit-chain result requires investigation; a working download is not an intact-chain assertion. If inventory or attribution storage is unavailable, retry after service is restored rather than presenting an incomplete screen as a finished review.

Use Documents to retain clear references and descriptions. The evidence workbook includes relevant recorded document metadata and links, not a promise that every linked file is present or authoritative. Keep the source records needed to resolve each gap. Follow the linked official guidance for program requirements; the application records do not certify eligibility or compliance.

USAC: Document retention: https://www.usac.org/e-rate/resources/document-retention/
USAC: Equipment transfer and asset records: https://www.usac.org/e-rate/applicant-process/before-youre-done/transfer-of-equipment/
Limits of this guide
This guide describes application behavior and summarizes the linked USAC retention guidance as reviewed on 30 September 2026. It does not determine eligibility, filing acceptance or compliance for any funding request.
Evidence exports describe the selected recorded data and document references. They are not an independent verification of the funding file.
The year selector cannot yet start an export for only undated equipment, or for a year that appears only in Documents.
Some corrections described here, including cycle imports that keep existing status and scope, and the newer access and concurrent-save checks, may not be in your installed version. Check your release notes.

Permissions, departments and Administrator EX
Assign appropriate access, understand why a page or record is restricted, manage department rules, and verify changes without confusing visibility with authority.

Understand the three checks before changing access

A person's tier establishes ordinary capabilities. Page rules then determine which actions are available on a particular page. Record ownership adds another check when a person changes equipment maintained by another department. Treat these as separate questions: can the person open the page, can they perform this action, and may they change this record? A visible row or an enabled navigation link alone answers none of the later questions.

Use the person's actual identity and assigned department when reviewing access. A directory account takes the highest-ranked tier group it belongs to. Without one, its stored assignment applies, then the administrator group, then the default tier. Removed access is different from a low tier: the record remains to identify the person in history, while sign-in is refused. Do not create another identity to work around a restriction.

Choose the appropriate tier

Choose a tier for the responsibility the person has, then narrow page access as needed. Do not promote someone to Administrator EX merely to make one button work. A department administrator may open the audit-log page but does not receive district-wide audit rows through that capability alone. Auditor and Administrator EX have the separate district audit capability.

Administrator EX is a deliberate exception to page-rule denials. A Block assigned to its department or its named account will not remove its page actions. Testing restrictive rules while signed in as Administrator EX therefore cannot demonstrate how an ordinary account behaves.

Monitor | View permitted pages; no ordinary write or export capability.
Auditor | View and export permitted information; no ordinary writes. Includes district audit access.
Operator | View, export and perform permitted operational writes; no general structural administration.
Department Admin | Operational and structural rights within one department; department and page restrictions still apply.
Administrator EX | All page permissions, shared administration and cross-department authority; department and personal page denials do not restrict this tier.

Review department and person rules

In Page permissions, choose whether the rule applies to A department or A specific person. Select the department, then the person when appropriate. Department administrators are limited to subjects they may manage within their department; Administrator EX can work across departments. Confirm the selected subject before editing a whole row or column.

Each action can be Inherit, Allow or Block. Inherit follows the tier and then the applicable department rule. A named-person decision overrides the department decision for that action, but ordinary View, Download, Create, Edit and Delete permissions remain bounded by the person's tier. Blocking View also disables the other page actions, so a separate Edit allowance cannot reopen a hidden page.

The underlying access policy also supports named-person Design delegation for a specific page, without granting ordinary editing or general structural administration. The ordinary Page permissions grid does not display a Design column. If an existing design delegation affects the case, ask an administrator to review that delegation separately rather than assuming the visible five-action grid describes every capability.

Save a controlled permission change

1. Identify the page and action the person needs. Review the tier, department and any personal rule before editing.
2. Change the smallest appropriate set of cells. Use whole-row or whole-column controls only after checking the selected person or department and the pages affected.
3. Review the changed-page count and choose Save. Unsaved drafts are not active permissions.
4. If saving stops partway through several page rules, review what is already stored. The page saves rules individually; earlier successful rules can remain saved even if a later rule fails.
5. Reload after a version conflict and compare the newer rule before trying again. If the outcome is reported unknown, read the saved rules first rather than repeating a possibly committed change.
6. Verify both the intended allowed action and an action that should remain refused using the affected account. Reload the page or sign in again where required to obtain current access.

Reset rules without mistaking inheritance for permission

Discard changes removes the current unsaved edits. Reset every page to inherited removes stored rules for the selected subject after confirmation; it does not assign a new tier or grant all actions. The resulting access still comes from the tier, department policy, page requirements and record checks. A personal reset can therefore reveal a department Block that a personal Allow previously overrode.

When an API refuses a request, do not assume the screen is merely hiding a feature incorrectly. Direct requests are checked too. A missing or unavailable permission store can refuse access rather than guess. Keep the original error, subject and page details when asking an administrator to investigate.

Distinguish department visibility from ownership

An asset's owning department identifies who maintains it. For ordinary accounts, a foreign owner can make an otherwise visible asset read-only. The server also checks attempts to assign a different owning department, preventing a person from bypassing the boundary by changing the owner while editing. Administrator EX has cross-department authority; an ordinary administrator does not acquire it merely through structural permissions.

Page visibility and department ownership are not a promise that every record in every feature is globally visible. Some pages and reports apply their own permitted scope. When troubleshooting, compare the actual page, account department and record owner. An asset with no recorded owner is also distinct from one explicitly assigned to another department; establish the correct owner through the approved record workflow.

Maintain departments and directory mappings

Only Administrator EX can change the shared department configuration or review department removal impact. A department may supply its label, directory mapping and navigation configuration. Saved directory mappings override the corresponding defaults, and removed mappings are represented explicitly. Review existing assignments when changing a mapping; changing navigation is not the same action as transferring ownership of equipment.

Before removing a department, review its usage. References include people, page rules, assets, closets, designs, custom pages and notices. Cenovel refuses removal while references remain. Reassign or resolve those records deliberately, then request the impact review again. Do not try to remove a department by repeatedly submitting the same rejected form.

Resetting departments has a preview of what would change. It also checks whether a removed department is still referenced. The reset preserves category claims, branch lists and colours where shipped defaults do not define replacements. Read the preview rather than assuming Reset empties every department setting.

Preserve accountability and verify the outcome

Permission-rule changes are versioned and recorded with their audit information. Department saves and resets record security audit entries describing the change. People whose access is removed remain identifiable in historical records. Use these records to explain who changed access and what was stored; an audit entry is not proof that every downstream account has already refreshed its session.

For a refused request, collect the page, action, person, department, record owner and exact message. For a successful change, revisit the effective permissions and perform one representative workflow. Verify department boundaries with an ordinary account and Administrator EX behavior separately. This keeps an intentional privilege exception from concealing an error in the policy intended for everyone else.

Limits of this guide
Tier descriptions summarize ordinary capabilities; individual features can add page, ownership, workflow or approval requirements.
The access policy supports named-person Design delegation for a page, but the ordinary Page permissions grid does not show Design, so this guide does not describe a way to change it.
This guide was checked against the application source; it is not a test of your installation.

Audit history, integrity and evidence
Interpret recorded changes, investigate operational failures and export retained audit evidence with a clear understanding of what integrity verification establishes.

Start with the question you need to answer

Use Security › Audit Logs to investigate recorded changes and sensitive actions. Use a record's own history for its workflow context, such as a return, completed RMA or disposal. Use Security › Diagnostics to investigate operational errors. These sources overlap through identifiers and audit events, but each answers a different question.

A before-and-after record describes values captured by the application. It does not independently establish that equipment moved, a repair worked or a device reported those values. Compare the record with the relevant observation, physical check or supporting document. Keep the observation time separate from the time somebody entered or changed information.

Find an event without overstating the search

1. Open Audit Logs and review Events, Span shown and Chain under Audit trail standing. These describe the displayed history and the latest chain check; they are not a count of everything that happened in the district.
2. Choose an Event kind where available. Use Search audit events for an action, actor, record or correlation ID, and Filter by actor to narrow the loaded rows.
3. Check any notice about the loaded window. Search cannot find entries older than that window. Load next 100 reveals more of the matching loaded history; it does not promise an unrestricted historical search.
4. Open the event and confirm its action, actor, target and time. A name is the name recorded in that event. A deleted target can remain identifiable in history without being an available current record.
5. Open Record evidence to inspect Correlation ID and Entry digest (SHA-256). Copy correlation id when coordinating an investigation; retain the event ID and exact time as well.

Interpret changed fields and missing values

Changed fields shows Before and After when both snapshots exist. A one-sided event instead shows Recorded values or Previous values. No field-level change was recorded for this event means that a comparable field change was not captured; it does not cancel the event or establish that nothing happened.

Not set represents an empty recorded value. Not recorded for a correlation ID or digest means that evidence is unavailable in that field. Sensitive values are redacted, and large or deeply nested payloads are bounded. Audit history is therefore not a complete backup of every value or secret.

Check exact timestamps when ordering events across time zones. Some workflow history contains a calendar date rather than a precise instant. Do not infer an hour from a date-only record or equate an operator-entered occurrence date with the application's recording time.

Understand who can see the evidence

Page access, action permission and account capability all matter. District audit rows do not carry a department. Administrator EX can always read the district-wide history. An Auditor can read it unless a page rule blocks Audit Logs. A Department Admin may open the page but sees a scope notice instead of district entries.

An accessible asset's change history can show event summaries and changed-field names without granting access to the underlying before-and-after values. Detailed values additionally require audit access. Workflow histories follow their own inventory page permissions. A visible record does not automatically grant permission to export district evidence.

Export evidence requires Download on Audit Logs and district audit capability. Diagnostics has a separate administrator access requirement; changing a resolution or running a validation script additionally requires Edit. Ask an authorized person to retrieve evidence when access is denied rather than interpreting a restricted view as an empty history.

Audit data in Explore, its exports and saved reports also need district audit access. Permission to open an analytics page does not grant access to district audit records. Administrator EX and auditors retain their permitted audit access; a Department Admin does not gain it through an alternate report.

Read the chain result precisely

About this chain explains segment boundaries and older entries. Separate segments verify independently; pre-chain entries have individual content digests rather than links establishing a continuous chain. The ordinary chain check validates live rows and archive checkpoint links. It does not reread every archive file; the evidence export performs that additional check.

A digest detects disagreement with specified stored content. It does not prove factual accuracy, a person's intent, completeness of all real-world actions, or resistance to someone able to rewrite both content and hashes. The event digest covers the documented fields, including actor, snapshots and previous digest, but excludes the event ID and occurrence timestamp. It is not an independent time attestation or digital signature.

Verified | The checked event content and links satisfy the implemented verification rules. Read the check time and segment explanation.
Broken at entry | Verification found a mismatch at the identified entry. Preserve the details and investigate.
Could not verify | The check could not run. Integrity is unknown; this is not a confirmed broken chain.
Not verified yet | There is no completed verification result since startup. Wait for a result before relying on it.

Illustration: Actual isolated desktop console after the explanation was corrected. About this chain distinguishes archived records from live database copies. A displayed routine chain result does not establish that every archive file was reread.

Export and retain a verified package

1. Choose Export evidence. The operation verifies and gathers retained live events and sealed archive segments, independent of the current table filters.
2. Keep the resulting CENOVEL-AUDIT-EVIDENCE dated .json.gz file with the investigation. Review generation time, event counts, first and last IDs, segment details and verification statement.
3. For an independent checksum comparison, decompress and parse the JSON, serialize its evidence member compactly with JSON.stringify, and calculate SHA-256. Compare that value with manifest.contentSha256. Hashing the compressed file or indented JSON produces a different value.
4. Preserve the original package and record where it came from. The package checksum covers exported evidence, including its timestamps, but a checksum supplied alongside content does not authenticate its source. The export action is itself audited after the package is assembled.

Investigate failures and unavailable evidence

In Diagnostics, choose Open, Resolved or All, then filter severity, source or Search diagnostics. Review the correlation ID and failure details. Marking an error resolved records an administrative decision and note; it does not perform a repair. Reopen restores its investigation state. Those resolution changes produce audit events.

Show validation scripts and retention exposes allowlisted checks, their timeout and results. A passed script establishes only that check's result. Resolved-error retention is separate from audit retention; it is not a control for deleting audit history.

Unavailable storage, unreadable archives, failed verification or export ceilings can prevent a download. The current export ceiling is 100,000 events and 64 MiB of uncompressed JSON. Escalate the precise failure rather than presenting a partial selection as the complete package. Sealing an archive can remove its live database rows after verification while retaining evidence in the archive; archive availability remains essential.

Limits of this guide
This guide is based on the application source and focused automated checks, including a refused export of a deliberately corrupted archive. It is not an acceptance test of your appliance.
Routine chain verification checks live rows and the links between archives; an evidence export also rereads the archive files. A verified archive transfer can remove the covered live rows while keeping their archive evidence.
Event digests leave out occurrence times and event IDs. The export checksum covers the exported values but is not an independent timestamp or a digital signature. Integrity checks do not certify that the recorded events were operationally true or compliant.
The rule that audit data in analytics needs district audit access may not be in your installed version. Check your release notes.

Importing and exporting inventory
Prepare a spreadsheet, review identity matches and partial results, and export a clearly scoped copy of the records you can access.

Choose the workflow that matches the data

The inventory Import action reads asset rows. Site survey imports and funding schedule imports have their own formats and workflows; a workbook accepted by one is not automatically suitable for another. Start from the template for the page you intend to change.

An import updates the application record. It does not configure the physical switch, prove a reported location or replace a backup. Keep the original file so you can compare the submitted data with the result. Create permission is required to open the asset import; existing-record updates still have their own server authorization and ownership checks.

Prepare an asset file

If a workbook is refused as damaged or unsafe, no inventory records have been written by parsing it. Obtain a fresh copy or resave it as a standard Excel workbook, then review the detected table before importing. A smaller file is not necessarily safe: Cenovel also checks the expanded contents and consistency of its archive headers.

1. Open Import in the asset register and download the template. Fill the Assets sheet with one physical asset per row; the Example reference sheet explains values and should not be imported as equipment.
2. Provide a serial and a model name already present in the catalog for every row. Model name matching ignores case but does not create a new catalog product from arbitrary spreadsheet text.
3. Keep identifier columns as text so spreadsheet software does not remove leading zeros. Record the actual asset tag when present; an absent tag does not require an invented number.
4. Choose the CSV or Excel file, then inspect the detected column mapping. Serial, Serial Number and S/N are supported header variations. Verify the chosen table and columns instead of assuming detection always selected your intention.
5. Review Where these land. Use current filter uses the current scope's status and location; otherwise choose the destination deliberately. Review funding values applied to every row.
6. Read the confirmation before starting. Existing serial or MAC matches can be updated, while unmatched rows can create new records.

Understand matching and what is preserved

The importer's existing-record update deliberately leaves status out of its patch. Do not use the file's destination defaults as a promise that every matched record changes status. Review each matched item's saved placement and status; use the normal move or edit workflow for an intentional lifecycle change.

Custom values are limited to fields supported by the resolved model. For access-point imports, reported switch information can help resolve closet placement and a stack link. An imported asset, a resolved closet and a saved link are separate outcomes. Missing or ambiguous switch context requires review rather than a guessed link.

Unique existing serial | The existing asset is updated using an exact serial lookup that ignores letter case and ASCII whitespace. Matching happens before pagination and keeps the account’s viewing restrictions. More than one visible matching record is refused; Cenovel does not choose one arbitrarily.
No serial match, usable MAC supplied | The importer checks for a matching hardware address. Multiple matches are refused rather than resolved arbitrarily.
No existing match | A new asset can be created after the row passes validation and its model is resolved.
Blank or unknown model | The row is skipped with a reason. Creating the asset does not implicitly create a catalog model.
Blank optional value on an existing asset | Blank imported values are omitted from the update; they do not clear the existing field.
Serial belongs to deleted inventory | The importer reports the deleted record for review. Restore it when appropriate, then rerun the import to apply the file's updates.

Reconcile the import result

Rows are processed independently. Some can save while others are skipped or fail. Read the imported count, skipped rows, missing-fieldset warnings, closet-review list and stack-link failures. Choose Download error report when it appears, then correct the records or source rows it names.

A saved asset with an unsaved stack link is still a saved asset. Reopen it before retrying. If the connection is lost, inspect the actual records and compare identifiers before repeating the file; do not assume an unanswered request rolled back the import. A repeat should be reviewed as an update opportunity, not treated as a guaranteed no-op.

Illustration: Actual isolated desktop import. The model was not in the catalog, so the row was skipped. Read the complete reason, resolve the catalog or file mismatch and review the import again.

Export the intended scope

A failed export leaves the chosen scope and columns available for correction or retry. Closing the dialog cancels pending record retrieval and prevents a pending workbook or CSV package from starting its download. Local packaging already underway may finish internally, but its canceled result is discarded. A download that has already started belongs to the browser and is not recalled by closing the dialog. A successful export is a point-in-time copy of permitted records, not a continuously updated inventory or an independently certified audit result.

Use the E-Rate evidence workflow when the purpose is a funding review, and the appliance backup procedure when the purpose is recovery. These outputs answer different questions and do not replace one another.

1. Open Export with Download permission. Confirm whether you want selected records, the current page, or everything matching the current filters.
2. Choose the columns and output format. Workbook produces an Excel file; CSV with metadata produces a ZIP containing interchange data and its context.
3. Check the search, model, location and funding filters before downloading. The export represents records available to your account, which may not be the entire estate.
4. For a filtered request exceeding the 5,000-record fetch limit, narrow the filters and try again. The screen reports the limit instead of downloading a silently truncated file.
5. Open the file and review its scope, generation context, column selection and record count before sharing or treating it as evidence.

Limits of this guide
The asset-file workflow is separate from site survey and funding schedule imports.
Very large spreadsheets, every workbook layout and interrupted imports need broader validation.
Exports are permission-filtered recorded data, not complete backups or compliance certification.
Workbook safety checks were tested against a limited set of malformed files and do not prove safety for every spreadsheet.