Decommission

Decommission finds assets that appear to have been retired and passes them to the system responsible for recording it. This page covers defining an action, reviewing candidates, and the export history. Concepts has the overview.

Decommission has to be enabled for your organization; if saving an action fails with a message that decommission workflows aren't enabled, contact FireMon Support. Creating actions and approving or rejecting candidates needs the Administrators or Project Managers role.

The Decommission page

Decommission in the navigation menu has three tabs:

Tab	What it shows
Decommission Candidates	Every candidate across all actions, most recently updated first, with its status, the asset, the action that found it, and the destination it goes to. Filter by Action and Status, or type a term to match the asset's ID, name, hostname, MAC address, account, type, or IP addresses. Candidates load 200 at a time as you page through, and the count reads <n>+ candidates until all have loaded; a later batch can hold a more recently updated candidate, which sorts into place when it arrives.
Actions	The actions you've defined: Name, Filters (the criteria), Type (Automatic or Manual), Project, and Changes.
History	Every export attempt, with charts by the integration the asset came from and by day.

Actions

An action is a saved set of criteria that identifies decommissioned assets, plus where to send them. Click New Action on the Actions tab:

Field	What it does
Name	Shown on every candidate the action finds.
Update	Automatic approves every candidate as it's found. Manual holds each candidate as Pending Review until someone approves it, and exports it on approval. Permanent.
Project	The project the action belongs to. Permanent.
Destination	The accounts approved candidates are exported to. Only accounts that can receive them are listed, currently ServiceNow accounts; see Decommissioned asset export.
Decom Candidates	The criteria, and a preview of what currently matches.

Criteria

Criterion	Keeps items that...
Change Type	had this kind of change recorded: Delete (the item disappeared from its source), Update, or Create. A new action starts with Delete. If you remove it, the action matches every kind of change, not just deletions.
Last Hit	last matched a firewall rule more than the given number of days ago, or have never been seen matching one.
Last Seen	were last seen by their source more than the given number of days ago, or have no last-seen date.
Account, Environment, Project, Region, Type, Vendor	came from the selected accounts, environments, projects, regions, types, or sources.
Tags	carry any of the given tag keys and values.
Attributes	have a raw attribute with a given value, by JSONPath. Attribute shortcuts saved on an account appear here as one-click buttons; see Attribute shortcuts.

The Last Hit and Last Seen dates come from whichever integration has them. Security Manager reports rule hits, and a 30-day hit count, for its network objects; Guardicore and ServiceNow report when they last saw an asset. Connect matches related items across integrations by IP address, hostname, and MAC address and takes the most recent value from any of them, so a server deleted from Azure can still show when its Security Manager object was last hit.

Finding candidates

When you save an action, Connect searches the inventory change history for items matching its criteria, gathers the related items from other integrations, applies the Last Hit and Last Seen conditions, and records each result as a candidate. From then on, whenever an item is deleted from its source, every action whose other criteria it satisfies gains a new candidate; Change Type applies to the initial search. Saving an action again rebuilds its candidate list from scratch, and every decision is lost: a Manual action's candidates all return to Pending Review, including ones already approved or rejected, and an Automatic action exports every candidate again.

An asset that's decommissioned in one place usually still exists in others: its firewall objects, its CMDB record, its IPAM entry. The candidate carries the deleted item and everything Connect matched to it, so the export can say what else needs cleaning up.

Export behavior

Automatic actions export candidates as they're found. Manual actions export a candidate when a person approves it. Every export attempt appears under History.

Candidates

Each candidate has a status:

Status	Meaning
Pending Review	Found by a Manual action and waiting for a decision.
Approved	A person approved it, and it's sent to the action's destination.
Auto Approved	Found by an Automatic action and exported without review.
Rejected	A person rejected it. Nothing is exported.

On the Decommission Candidates tab, or the Candidates tab of an action, select pending candidates and click Approve or Reject. Both ask for confirmation. An approved candidate is sent to the destination, and a rejected one is not exported. Only pending rows have a checkbox. Saving the action again discards these decisions.

Click a candidate's status to open it. The page shows the decision and when it was made, the action and destination, the last hit and last seen dates with the integration each came from, and the asset: account, region, vendor, type, IP addresses, hostname, MAC address, and its 30-day hit count. Pending candidates can be approved or rejected from here too. Below that, Export History lists this candidate's export attempts, with when each was Sent and its Status.

History

The History tab lists every export attempt with the destination, the asset, and a State of Pending, Success, or Error. Hover an Error to read the message. The charts above the table break attempts down by the integration the asset came from and by day, and the filter bar narrows the list by account, action, destination, State, and more.

Deleting an action

Deleting an action removes it, its candidates, and its export history from Connect. Anything already exported stays in the destination.