Skip to content

Suggested App-to-App

Purpose

Suggested App-to-App is the Clarity Transform review queue for proposed dependencies between two confirmed applications. It is the last stage of application inference: earlier stages work out which devices talk to each other and which devices make up an application, and this stage asks whether one confirmed application depends on another. The on-screen subtitle reads: "Dependencies between two confirmed applications, derived from devices in one talking to devices in the other. Accept writes the dependency to the CMDB for wave and move-group planning; suppress stops later runs re-proposing it. Needs at least two confirmed applications - promote candidate applications first."

Where the rows come from

The suggestions are written by Run inference on Candidate Applications. This page has no run button. A run needs at least two confirmed applications, so promote candidate applications first, then run inference again.

Where to find it

Discover → Application Inference → Suggested App-to-App. The page header is Suggested App-to-App Relationships.

What you see

Filter buttons

Columns, Pending, Accepted, Suppressed and All. Columns shows or hides columns. The grid opens filtered to Pending.

Columns

  • Source Application Name
  • Target Application Name
  • Direction: Directed, Bidirectional or Undirected; values seen: Directed.
  • Evidence: the kind of signal behind the row: Corroborated, Observed or Permitted, strongest first, each in its own colour. The kinds are set on Evidence Sources: Observed is observed traffic, Permitted is a firewall permit, which allows traffic but does not show that anyone used it. Values seen: Observed.
  • Confidence: High, Medium or Low; values seen: High.
  • Status: Pending, Accepted or Suppressed.
  • Device Pair Count: the number of device conversations behind the row.
  • Contributing Pairs: the device pairs behind the row, so the row can be traced to its source.
  • Observation Count
  • Last Seen
  • Contributing Sources: the integrations that supplied the evidence; values seen: NetFlow.
  • Actions: the row actions below.

The data also has resolved, unresolved and conflicting conversation counts and First Seen, which are hidden by default and shown with Columns.

There is no create or edit form.

Row actions

  • Accept - write the app-to-app relationship: opens the Accept Dependency dialog, which asks "Record source depends on target?" and explains "An app-to-app relationship is written to the CMDB. Wave planning, move groups and the migration risk dashboard all read these, so this dependency will start affecting planning." The buttons are Cancel and Accept.
  • Suppress - never re-propose: opens the Suppress Dependency Suggestion dialog, which asks "Suppress the suggested dependency from source to target?" and warns "Inference will never re-propose this pair. This cannot be undone." The buttons are Cancel and Suppress.

The row actions are shown only on Pending rows. An Accepted or Suppressed row shows a dash.

Messages

  • After Accept: "Dependency accepted."
  • After Suppress: "Suggestion suppressed."
  • If the action is refused, the message gives the reason, for example that one or both applications no longer exist, or that the suggestion is already accepted. With no reason, it reads "The action failed."

The dialog's confirm button is unavailable while the request is in progress.

Filters

The grid remembers its Search: text, column filters, sort order and page size between visits. If the grid shows fewer rows than you expect, clear the Search: box and the filter row.

How to

Review the suggested dependencies

  1. If you have promoted applications since the last run, first select Run inference on Candidate Applications.
  2. Go to Discover → Application Inference → Suggested App-to-App.
  3. The grid opens filtered to Pending, the suggestions still to decide.
  4. Read Evidence and Confidence together: confidence says how sure the suggestion is, and evidence says what it rests on. Corroborated ranks above Observed, and Observed above Permitted.
  5. On anything surprising, read Device Pair Count and Contributing Pairs. A single contributing pair behind an application-level dependency is worth checking before you accept it.
  6. Select Columns and show the conflicting conversation count. A row with conflicting conversations has evidence that disagrees with itself: investigate it before you accept or suppress it.
  7. To accept the dependency, select Accept - write the app-to-app relationship. The Accept Dependency dialog opens. Select Accept, or Cancel. Accepting writes the dependency to the CMDB.
  8. To reject it, select Suppress - never re-propose. The Suppress Dependency Suggestion dialog opens. Select Suppress, or Cancel. Later runs do not propose a suppressed pair again and suppression cannot be undone, so leave a row pending rather than suppress something you have not ruled out.

When you next select Run inference, the result banner reports pairs "left alone - already accepted or suppressed" and pairs "not proposed - the dependency is already recorded". If it reports pairs "not proposed because the per-run ceiling was reached", the queue is incomplete: decide the rows that are there, then run inference again.