1 What is Action Manager?

ArchFX Action Manager is the workflow engine that enables factories to detect abnormal conditions, alert the right people, and follow standard procedures for fast resolution. It brings together triggers, routing rules, playbooks, AI-generated insights, and performance analytics to ensure your teams keep production running efficiently at all times.

Think of Action Manager as your real-time escalation and SOP automation platform inside Arch, designed for operators, supervisors, manufacturing engineers, quality teams, and line leaders.

AI-Guided Actions: Intelligence Built Into Every Alert

One of the most powerful capabilities within Action Manager is its AI-Guided Actions.
Every time a trigger fires, Action Manager automatically analyzes:

• the data associated with the event

• the surrounding operational context

• historical behaviors

• relevant KPIs and dashboards

Using this information, the system generates an AI-crafted summary that highlights:

• when the issue started

• where it occurred

• how it compares to recent behavior

• and in many cases, a potential root cause or the most likely contributors

This summary is automatically attached to the action, meaning users do not need to navigate dashboards or perform manual investigations to understand what happened.

Why This Matters

AI-Guided Actions transform Action Manager from a simple alert system into a decision-support tool, reducing the cognitive load on teams and enabling faster responses.

Benefits include:

• No need to be a data expert: Operators and supervisors get immediate, contextual insights without searching through data.

• Skill elevation: Frontline users learn from AI explanations, improving their understanding of process behavior over time.

• Faster triage: Users can respond in seconds because the system tells them what’s happening and often why.

• Consistent interpretation: Everyone receives the same explanation, reducing variation in decision-making.

• Better root cause identification: AI surfaces abnormalities, trends, and correlations that may not be visible in a quick dashboard glance.

With AI-Guided Actions, Action Manager becomes not only a notification system, but a smart assistant that helps teams close the skills gap, move faster, and improve problem-solving across the factory.

2 Why Action Manager Exists

Modern factories run hundreds of processes that must stay within strict performance ranges—cycle time, throughput, yield, attrition, downtime, machine behavior, and more. When any of these metrics deviate from expected values, teams need to know immediately, understand why, and respond quickly to avoid lost productivity.

Traditionally, this requires expert users who know where to look in dashboards, how to interpret trends, and how to connect data across multiple systems. Action Manager eliminates this barrier.

Automated Detection + Intelligent Guidance

Action Manager continuously monitors manufacturing data and automatically detects abnormal conditions using configurable triggers and rules.
But detection alone isn’t enough, users need clarity and context.

That’s why Action Manager includes AI-Guided Actions, a capability that transforms raw alerts into actionable insights.

When a trigger fires, Action Manager:

• Analyzes the event data and surrounding context

• Reviews historical patterns

• Looks at relevant KPIs and dashboards

• Summarizes what changed, when, and where

• And often suggests likely root causes or contributing factors

This AI-generated summary is automatically attached to the action, giving teams a clear, concise explanation without requiring them to navigate dashboards or interpret complex graphs.

Reducing Dependency on Experts

Instead of relying on a handful of highly skilled analysts or engineers, frontline teams gain:

• Immediate understanding of the issue, with no need to dig into charts

• Faster triage and response times

• A consistent interpretation of events, reducing guesswork

• Skill improvement, as AI explanations teach users how the process behaves

Action Manager ensures that any user, operator, supervisor, engineer, can take the right action at the right time, supported by real-time intelligence.

Preventing Escalation and Downtime

By combining automatic detection, intelligent summaries, and structured playbooks, Action Manager helps factories:

• Avoid prolonged downtime

• Standardize responses to recurring issues

• Shorten the time from detection to root cause

• Improve quality and yield

• Empower teams across all shifts and sites

In short: Action Manager exists to make manufacturing smarter, faster, and more resilient, powered by automation, structured workflows, and AI-guided insights.

3 Accessing Action Manager

Signing in to ArchFX Cloud

Users log in via app.archfx.io and select the correct customer instance.

Opening Action Manager

From the left navigation menu select Action Manager.
If the module doesn’t appear, email help@archsys.io to request access.
 

4 Availability & Home Page

Before Action Manager can route alerts to a user, the system needs to know who is actually available at that moment.
In real factory environments, production schedules are dynamic, operators may step away to support another line, attend a meeting, join a quality review, or handle maintenance tasks. Because of this constant movement, it is not realistic to assume a user is always ready to receive alerts.

Why Availability Matters

Action Manager introduces an explicit “Available” status to solve this challenge.
When a user logs in, they start as “Not Available.” By clicking Mark Self as Available, they indicate that they are currently:

• On shift

• On the floor

• Ready to receive and respond to alerts

This ensures alerts are routed only to people who can realistically take action, preventing delays and reducing escalations caused by unavailable team members.

Two Common Availability Use Cases

1. Standard Use Case (Role-Based Availability)

Each user marks themselves available during the shift.
Action Manager then routes alerts based on:

• Their availability

• Their group membership

• Their fair share of workload

This model works well when each operator, technician, or engineer handles their own alerts and resolves them directly.

2. Control Tower Use Case (Central Dispatcher)

Some factories use a centralized “control tower” model:
A single user or a small team stays always available and receives all alerts.
They then coordinate onsite resources, often redirecting tasks to whoever is physically closest or best suited.

This model works well for:

• High-volume factories

• Centralized support centers

• Multi-line operations needing quick dispatching

Home Page Overview

The Home Page displays:

• Availability state

• Pending actions

• Recent alerts

• Quick navigation to Groups, Triggers, Playbooks, and Activity Feed
   

5 Managing Groups

Groups are a core part of how Action Manager routes alerts. A Group represents a team, function, or role that should collectively receive alerts for specific triggers. Every customer defines their groups based on how their operations are organized. This means there are no fixed rules, and you can build groups that match your real production responsibilities, whether that is a single technician or an entire department.

In the Groups page, you can see a complete list of all groups for your organization, along with the user who created each one. The table supports filtering by group name or by site, making it easy to locate groups in large deployments.

Suggested screenshot location:

Customer Ownership and Flexibility

Groups are fully customer-defined. You decide:

• How many groups to create

• Whether a group contains one person or many

• Whether groups are site-specific, line-specific, process-specific, or role-based

This flexibility allows Action Manager to adapt to any factory structure.

Examples of Valid Group Structures

• Single-user groups:
  For environments where each technician is directly responsible for their own alerts.

• Multi-user groups:
  Ideal when several operators or engineers share responsibility and availability rotates.

Best Practices for Group Naming

To ensure clarity and traceability, especially when reviewing actions or building escalations, it is recommended to use consistent, descriptive naming conventions.

A well-named group helps everyone understand:

• The site

• The function or responsibility

• The line or area (optional)

• The customer or product (optional)

Recommended Naming Format

Site_Area/Function_Role_Customer/Line

Examples

• Guadalajara_Test_Technitian_CustomerA

• Suzhou_B3_L4_Manufacturing_R1

• Customer_Line2_Quality_AOI

Clear names help during troubleshooting, analytics, escalations, and when browsing actions that occurred across sites.

Creating a New Group

To create a group, click the Add new button on the Groups page.

Suggested screenshot location:

You will need to:

1. Enter a Name; following your internal naming convention

2. Select a Site; this determines where the group is valid

3. Click Confirm

Adding Members to a Group

When a new group is created, it starts with zero members.
You must manually add members before the group can receive alerts.

Important Requirements

A user must meet these conditions before they can be added:

1. Have access to Action Manager (permission granted by Arch or your admin)

2. Have access to the specific site selected for the group

If either condition is missing, the user will not appear in the member selection list.

How to Add Members

1. Open the group

2. Click + Add

3. Select the user(s) from the list

4. Save

Suggested screenshot location:

This ensures that only authorized and properly scoped users receive alerts from this group.

Profiles Inside a Group

Each group also includes a Profiles tab.
A Profile is a configuration specific to an Action Manager module (for example Attrition Monitoring or Station Monitoring). Profiles control how alerts are routed inside a group for that particular module.

You can create as many profiles as needed, depending on how granular your routing rules must be.
A deeper explanation of profiles will come later in the tutorial, at this stage, it’s enough to understand that they allow groups to behave differently per module.

6 Trigger Management Overview

Triggers are the core engine behind how Action Manager detects issues. Each trigger belongs to a module, and each module is designed to identify a specific type of anomaly in manufacturing data, such as attrition spikes, cycle time deviations, downtime conditions, or job-level irregularities.

Below is an image showing an example list of available trigger modules.
This list may vary depending on the customer instance, permissions, or the Action Manager features enabled for your organization.

Browsing Triggers by Location

Use the Location tab to navigate site → area → line → machine and view associated triggers.
 

7 Creating & Editing Triggers

In this section, we will walk through how to use a Trigger Module to create a Profile.
This page provides a detailed explanation of the configuration process so you understand every setting. In later sections, when reviewing specific modules, we will focus only on the parameters relevant to that module.

Think of this as your complete reference for how profile creation works across all modules.

Viewing Existing Profiles Within a Module

When you click on a module, Action Manager displays all the profiles that have already been created for that module.

Here you can:

• Filter profiles by status

• Search by site

• Search by profile name (Description)

Profile Status Types

Each profile shows a Status, which indicates whether the profile is active and properly configured:

This overview helps you quickly identify which profiles are ready, which need attention, and which are paused.

Creating a New Profile

To create a new profile, click the Add New button at the top of the module page.

You will now see a configuration screen that includes:

• Description

• Site

• Scope

• Group

Let’s break down each field.

1. Description (Profile Name)

This is the name of the Profile. It should follow a clear naming convention to help other users understand:

• What anomaly is being monitored

• The threshold or rule

• The scope (optional but recommended)

A good description improves filtering, escalations, reviews, and historical analysis.

Recommended naming style

Use context + threshold + scope:

• Attrition>0.15%_Line2

• Attrition>0.2%_SMT_B3

• CycleTime_>65s_Line12

This makes it immediately clear what the profile is checking and where.

Site Selection

The Site dropdown determines where this profile will apply.

After selecting a site, additional fields will appear, specifically: Scope.

Selecting the Scope

The Scope defines where the trigger will look for data.
Depending on your Factory Model, you can configure a profile to monitor:

• Entire Site

• A specific Area

• A specific Line

• A specific Machine or Module

Once you choose the level, click Add + to confirm the selection.

If you don’t click Add +, the scope will NOT be saved and the profile may show “NOT-SYNC.”

This ensures the trigger knows exactly which equipment or process to monitor.

Selecting the Group (Initial Routing Group)

The Group determines who will receive the alerts generated by this profile.

This is the base group (Level 1 routing).
Later, you can add additional escalation groups in the Routing section, but for now, the base group must be defined.

Important notes:

• Only groups associated with the selected site will appear.

• Groups must contain valid members (more details in the Groups section).

• This field is required for the profile to operate.

Summary of the Profile Creation Process

To create a new trigger profile:

1. Click Add New in the module page

2. Enter a descriptive Description following best practices

3. Select a Site

4. Select a Scope and click Add +

5. Select a Group to receive the alerts

6. Save

Once created, the profile will appear in the module list with its initial NOT-SYNC or IN-SYNC state depending on configuration completeness.

8 Configuring a New Profile

Once you have selected a Trigger Module and created a new Profile, the next step is to configure the specific parameters that determine how and when the condition will be evaluated. Most profiles in Action Manager rely on two key time-based settings: Check Every and Window.

Check Every

This parameter defines the frequency at which Action Manager inspects the database to evaluate the rule. In other words, it determines how often the system asks:
"Has the condition been met yet?"

For example, if “Check Every” is set to 1 minute, then every minute the system will run the query associated with the profile to verify whether the alert should fire.

Window

This parameter defines the time range that will be evaluated each time the condition is checked. It is the data window used to perform the calculation.

For example, in the Attrition module, the window is used to gather all misspicks and total placements within that time range, and then compute the core metric:

attrition = misspicks / total_placements

If the window is 10 minutes, the system will sum all the events from the last 10 minutes to evaluate the condition.

Module-Specific Parameters (Example: Attrition Module)

Attrition Threshold

This value defines the target threshold that the calculated metric must exceed in order to trigger an alert.
Depending on customer needs, the module allows setting the threshold either in PPM or % units.

Minimum Placement Count

This setting helps prevent false positives, especially during periods of low activity (such as startup or shutdown of a line). It establishes the minimum number of placements required before the system is allowed to evaluate attrition.

Example:

• If only 100 placements occurred, a single misspick results in 1% attrition.

• If your threshold is 0.5%, this could incorrectly trigger an alert.

• “Minimum Placement Count” ensures the system waits until there is sufficient production volume before checking the rule.

Level

The Level parameter defines the aggregation level used to calculate the metric. In the Attrition module, misspicks and placements can be accumulated across multiple resources—such as:

• A single machine

• An entire line

• An area containing several lines

• An entire site

This enables more holistic rules, such as:

• Attrition for a single SMT machine

• Attrition for Line B3 as a whole

• Attrition aggregated across the entire PCBA area

• Site-level attrition

⚠️ Important: Relationship Between Scope and Level

The Level must never exceed the Scope.

If your Scope is limited to a single line, you should not configure a Level of “Site”, because this leads to unexpected or limited behavior.

General rule:

Scope ≥ Level

Saving and Syncing the Profile

Once all parameters are configured, click Save to store the profile.

After a few seconds, the system will update the profile’s status. If everything is configured correctly, it will transition to:

IN-SYNC

If the profile shows NOT-SYNC, verify that:

• The Scope was added correctly (using Add +)

• Threshold, Minimum Placement Count, and Level values are valid

• A base Group has been selected

Once the profile reaches IN-SYNC, it will begin evaluating data according to the frequency defined in Check Every.

9 Selecting the Correct Values for a Profile

When configuring a new profile, one of the most important steps is determining the correct values for the rule, such as the threshold, window, level, and minimum counts. To help with this, every profile in Action Manager includes a link to the specific dashboard that provides the operational context needed to choose these values.

In this example, we will use the dashboard “Attrition Overview”, which helps visualize line and machine behavior for the Attrition KPI.

Using the Dashboard to Validate Your Profile Settings

When you open the dashboard using the link inside the profile, the filters at the top of the dashboard will automatically match the scope of the profile.
These filters include:

• Site

• Area

• Line

• Machine

This aligns the dashboard view with the Scope of your profile.
If needed, you can adjust these filters manually to match the exact scope you plan to monitor.

Match the Window with the Time Range Filter

The next step is to configure the time range so that it reflects the profile’s Window parameter.

• If your profile window is 1 hour, set the dashboard time filter to Last 1 hour.

• If your window is 30 minutes, set the dashboard to Last 30 minutes, and so on.

This ensures that the attrition values you see in the dashboard represent the same time window the alert will examine.

Recommendation:

Analyze multiple windows across the entire shift. For example:

• If the shift starts at 06:00 AM:

  • Review 06:00–07:00

  • Then 07:00–08:00

  • Then 08:00–09:00, etc.

This helps you understand whether the process behaves consistently or fluctuates throughout the day.

Match the Level with the Correct Dashboard Quadrant

The Attrition Overview dashboard displays information at multiple levels:

• Line-Level Attrition (upper-left quadrant)

• Machine-Level Attrition (upper-right quadrant)

The Level parameter of your profile must match the type of data you are evaluating:

• If your profile Level is Line, analyze the top-left quadrant of the dashboard.

• If your profile Level is Machine, analyze the top-right quadrant instead.

⚠️ Important Note

Machine-level behavior often has more variability because individual machines may experience isolated spikes.
Line-level values tend to be smoother because stable equipment compensates for anomalies in other machines.

This distinction is essential when selecting thresholds.

Choosing the Right Threshold

Once the scope, window, and level are aligned, the next step is selecting the threshold that will trigger the alert.

Your goal is to choose a value that:

• Reflects real operational variation

• Triggers meaningful alerts, not noise

• Helps teams take action when needed

• Fires a few times per day, not constantly, but not never

A good threshold is one that:

• Represents a value above typical performance

• Is sensitive enough to capture relevant deviations

• But not so aggressive that it fires all day long for normal behavior

Example Interpretation:

If machine-level attrition occasionally spikes to 2% but normally stays around 0.4–0.6%:

• A threshold of 0.6% might be too sensitive (constant alerts)

• A threshold of 2% might be too high (alerts only during critical failures)

• A good operational threshold might be 0.8–1.0%, depending on the customer objective

Validate Across Different Time Ranges

Because production varies across shifts, jobs, and product changes, always validate thresholds using:

• A few hours from the current shift

• Several hours from the previous shift

• Data from the last few days or weeks

This prevents thresholds from being tuned only to a “good day” or a “bad day” and ensures they work reliably across real conditions.

Key Goal When Defining a Rule

The purpose of an alert is not to overwhelm the team with noise, nor to only fire once a month.
The purpose is:

To notify teams of meaningful deviations that they can respond to and correct.

An effective alert should trigger a few times per day, helping:

• Identify trends early

• Take corrective actions

• Prevent bigger issues

• Improve overall process stability

If a rule never fires, it offers no operational value.
If a rule fires constantly, it loses credibility.

Your task is to find the sweet spot.

Example: Sensitivity Differences Between Line-Level and Machine-Level Rules

It is important to understand that the sensitivity of a rule changes significantly depending on whether the Level is set to Line or Machine (PnP module). A threshold that makes sense at the machine level may never trigger at the line level, and vice versa.

Here is a real example using a 1-hour time window:

• The line-level attrition for the selected line is 0.119%.

• However, within that same line and same hour, the machine with the highest attrition reaches 1.51%.

This illustrates a crucial point:

• A rule configured with a 0.5% attrition threshold and a 1-hour window
  would NOT trigger at the line level, because 0.119% is below 0.5%.

• But the same rule WOULD trigger at the machine level, because 1.51% exceeds the 0.5% threshold by a wide margin.

Why this matters

• Line-level thresholds smooth out anomalies because stable machines dilute the impact of a single outlier.

• Machine-level thresholds amplify anomalies, because each machine behaves independently and may spike for short periods.

This example reinforces why it is essential to match:

• The correct Level (Line vs. Machine)

• With the correct threshold

• Validated using the appropriate Window

A rule must reflect the behavior of the level it is monitoring—not a different one.

10 Routing and Escalation

Once your profile is configured and synchronized, the next critical step is to define how alerts are routed and how they escalate over time. This determines who receives the alert first, how the system distributes workload, and what happens if the issue is not addressed promptly.

To configure routing, click the Routing tab inside the profile. You will see several fields that define how alerts will flow through your organization.

Assign To

This is the group that will receive the alert when the profile triggers. The group selected here is the first level of recipients and must be aligned with the operational team responsible for resolving the issue.

If needed, additional groups can be added later as escalation levels.

Assignment Option

This setting determines how the alert is delivered to the group members. You have two options:

1. Automatically assign to a random user

In this mode, Action Manager selects a specific user within the group based on:

• Their availability

• Their current workload

This ensures work is distributed fairly and that alerts go to someone who is actually on duty and ready to take action.

2. None, Notify entire group

With this option, the system sends the alert to all members of the group at once.
This is recommended in scenarios such as:

• Control tower operations

• Multi-shift groups with shared responsibility

• Small teams where any member can respond

Notification Type

At this time, the only available notification method is:

• Email

Future versions may support additional channels, but currently all alerts will be delivered through email notifications, in addition to appearing inside Action Manager.

Default Priority

Each profile can be assigned a priority level from 1 to 5.
This is a user-defined setting and represents the importance, urgency, or operational impact of the alert.

Typical example:

• Low Priority (e.g., 0.3% attrition threshold):
  May trigger regularly at line level but does not represent critical risk.

• High Priority (e.g., 1.5% attrition threshold):
  Represents a severe operational anomaly that should be addressed immediately.

Priorities help teams differentiate between minor deviations and major issues, especially when monitoring several rules simultaneously.

Escalation

Escalation ensures that if an alert is not addressed within a reasonable time, the system automatically forwards it to additional groups for further action.

Escalate Automatically

If you check the “Escalate Automatically” checkbox, the system will escalate the alert after the number of minutes defined in the “Minutes to escalate” parameter.

For example:

• If “Escalate Automatically” is enabled

• And the parameter is set to 10 minutes

• Then after 10 minutes, if no user has taken ownership, Action Manager escalates the alert to the next group

This provides a structured escalation workflow and prevents alerts from being ignored or delayed.

Defining an Escalation Step

Each escalation level requires defining the same routing parameters as the first level:

• Assign To

• Assignment Option

• Notification Type

• Priority (optional)

The escalation chain can include up to four levels.

If you need an additional level, click:

“Add Escalation Level (Routing Step)”

This allows you to build multi-tiered escalation paths that match site procedures or staffing structure.

Important Notes on Escalation Behavior

• Once the alert escalates, it cannot be de-escalated.
  The alert remains assigned to the higher-level group even if someone lower-level becomes available later.

• Escalation only happens if:

  • No one has taken the alert

  • And the “Escalate Automatically” option is enabled

• Escalation ensures visibility and prevents alerts from being lost in busy shifts

11 Understanding and Managing Playbooks

Playbooks are one of the most powerful components of Action Manager because they bring site-validated knowledge directly into the hands of operators, technicians, and engineers at the exact moment an alert is triggered.

A Playbook is essentially a set of step-by-step instructions—written entirely by the customer—that explains how to diagnose, troubleshoot, or resolve a specific problem. Playbooks allow each site to capture expert knowledge, standardize responses, and guide teams through consistent, effective actions.

Playbooks can include:

• Text instructions

• Images

• Diagrams

• Process notes

• Troubleshooting checklists

• Site-specific best practices

This transforms Action Manager from a simple alerting system into a full operational guidance tool.

Playbooks Menu and Folder Structure

Inside the Playbooks module, customers can organize their content into collections (folders).
Each collection contains one or more playbooks.

What you will see:

• A list of collections created by the site

• A list of playbooks inside each collection

• A list of tasks (steps) inside each playbook

This structure helps teams group related playbooks (e.g., attrition troubleshooting, cycle-time issues, AOI quality guidance, etc.).

Linking Playbooks to a Profile

When creating or editing a profile, you can attach one or multiple playbooks to that profile.
This is done in the “Playbook” configuration section of the Profile settings.

Why this matters:
When the profile is activated and an Action is created, the linked playbook(s) will automatically appear inside the action window. This gives the user immediate access to site-approved guidance without needing to search or navigate elsewhere.

Using Playbooks Inside an Action

When an alert is triggered and an Action is created:

• The user will see the recommended Playbooks directly in the Action sidebar

• Each Playbook’s tasks will be shown in order

• Users can read, follow, and document their resolution steps

Inside the action, each task can also be ranked by the user.
This ranking provides valuable feedback to Playbook managers—for example:

• Which tasks were most helpful

• Which instructions are unclear

• Whether parts of the playbook should be updated or improved

This feedback loop helps Playbook owners maintain high-quality, effective documentation.

Creating a New Playbook Collection

To create a new collection:

1. Open the Playbooks menu

2. Click New Playbook

3. Select New Collection

You will be prompted to enter:

• Title

• Description

• Site

The title should be descriptive enough for users to identify the topic of the collection.
The description provides additional context (e.g., “Guides for resolving attrition issues in SMT lines at Site XYZ”).

Once the collection is created, you can add your first playbook.

Creating Your First Playbook

After creating the collection, click Create First Playbook.

You will now fill out:

• Playbook Title; clear, descriptive name (e.g., “High Attrition Troubleshooting Guide”)

• Playbook Description; short explanation of what the playbook covers

These fields help users understand when the playbook is relevant.

Adding Tasks to a Playbook

Once the playbook is created, you can begin adding tasks by clicking Add New Task.

Each task opens a rich text editor where you can:

• Write detailed instructions

• Insert images

• Add diagrams or screenshots

• Format lists or steps

Tasks should represent clear, actionable steps that an operator or technician can follow to resolve the issue efficiently.

Recommended number of tasks:

• Between 3 and 5 tasks for most scenarios

• More tasks only if necessary to cover complex troubleshooting

High-quality tasks significantly improve the effectiveness of Action Manager because:

• They reduce response time

• They provide immediate clarity during stressful situations

• They help new operators learn faster

• They standardize site-level problem-solving methods

Suggested Image:

• Screenshot of the task editor

12 Working with Actions

The Actions module is where users can monitor, review, and resolve all alerts generated by Action Manager profiles. Every action represents a real event detected on the production floor and includes all required context, data, and guidance needed to address it.

The Actions page shows only the actions within the scope assigned to the user:

• If you have site-level access, you will see actions for that site.

• If you have global access, you will see actions across all sites.

• If you have limited access, you will only see actions for the areas or lines you are authorized to view.

My Assigned Actions vs. Other Actions

The Actions module is divided into two main sections:

1. My Assigned Actions

These are the actions that:

• Are assigned directly to you, or

• Are assigned to a group you belong to

These are the actions you are expected to review or resolve.

2. Other Actions

This section lists:

• All other actions within your visibility scope

• Actions assigned to other users or teams

• Actions created by different profiles but relevant to the same site or area

This gives you a complete operational picture, even if you are not responsible for resolving every action.

Filtering and Managing Actions

From the Actions page, users can:

• Filter by status, priority, module, site, or date

• Search actions by keyword

• Sort by trigger time, priority, or assignment

• Open individual actions for detailed analysis

• Monitor overall activity and workload

This makes the Actions page the central operational hub for reviewing all alerts within the factory.

Viewing an Action — Action Details

Clicking on an action opens a detailed view that includes all context needed to diagnose and respond to the issue. Below are the key components displayed inside an action.

Summary (AI-Generated)

At the top of every action, you will see an AI-generated summary.
This summary is produced automatically based on:

• The data associated with the event

• Historical behavior for the metric

• The relevant dashboards

• KPIs and contextual changes detected

For example, in an Attrition event, the AI summary might explain:

• When the attrition increase started

• Which machine or head contributed most

• How the event compares to recent performance

Every module has its own behavior, so summaries will vary depending on the trigger.

Status Information

This section provides an overview of key action attributes:

• Assigned To: User or group responsible for resolving the action

• Priority: Priority defined in the profile

• Site: Where the action originated

• Source: The system or data stream that triggered the profile

• Module: The Action Manager module (e.g., Attrition, Cycle Time, Downtime)

• Profile Description: The profile that detected the event

  • A link allows you to navigate directly to the profile configuration

• First Trigger At: The first moment the condition was detected

• Last Trigger At: The most recent moment the condition was detected

This gives full visibility into the event and the configuration behind it.

Tasks (Playbook Recommendations)

If the profile has an associated Playbook, the recommended steps will appear in this section.

Users can:

• Read the steps

• Follow instructions

• Rank each task based on usefulness

• Add comments or details about what they did

This feedback helps Playbook managers refine instructions and improve future guidance.

Dashboards

Each action includes direct links to dashboards relevant to the event.
There are usually two types of dashboard links:

• Screenshot — Opens the dashboard with the exact timestamp of the event pre-loaded

• Live — Opens the dashboard in current live mode

This allows users to compare what was happening at the time of the alert versus what is happening right now.

Escalation Steps

If escalation was configured in the profile, this section displays:

• The current escalation level

• The groups involved

• The timestamp of each escalation step

• Whether additional escalations are pending

This provides a complete audit trail of how responsibility has shifted over time.

Resolving or Ignoring an Action

At the bottom of the Action window, you will find two options:

Resolve

Indicates that the issue has been addressed.
Users are encouraged to add a comment describing:

• What was done

• What was adjusted or corrected

• Any findings that may help others in the future

  

Ignore

Used when:

• The event was a false positive

• The alert was not operationally relevant

• The team intentionally decides not to address the alert

A comment explaining why the alert was ignored is strongly recommended.

Both actions update the status in the Activity Feed and close the action.

History Tab

The History tab provides a full log of all activity related to the action, including:

• Status changes

• Reassignments

• Escalations

• User comments

• Resolution notes

• Timestamped records of every modification

This ensures complete traceability for audits, reporting, and continuous improvement.

13 Activity Feed

The Activity Feed provides a high-level operational overview of how Action Manager is being used across the factory. This dashboard helps teams understand not only the volume of alerts being generated, but also how effectively they are being acknowledged, resolved, and escalated.

Because the Activity Feed runs entirely in Grafana, all standard filtering capabilities are available, allowing users to drill down by:

• Site

• Area

• Line

• Machine

• Module

• Profile

• Time range

This makes the Activity Feed a powerful tool for performance monitoring, process evaluation, and continuous improvement.

Overall Action Statistics

At the top of the dashboard, you will find a summary of the total number of actions within the selected time range. These stats typically include:

• Total Actions — The number of alerts generated

• Resolved Actions — How many were closed successfully

• Ignored Actions — Alerts dismissed as false positives

• Pending Actions — Still awaiting resolution

• Expired Actions — Alerts that were never acknowledged within the escalation or timeout period

• Ratio of Completed Actions — Percentage of resolved vs. total

• Number of Escalated Actions — How many required escalation

This section provides an immediate snapshot of how well the site is responding to alerts.

Average Resolution Time (MTTR)

The Mean Time to Resolve (MTTR) measures how long it takes, on average, for users to resolve an action.

A lower MTTR indicates:

• Faster reaction times

• Better operational responsiveness

• More efficient troubleshooting

A high MTTR may indicate:

• Insufficient staffing

• Poorly configured profiles

• Missing or unclear playbooks

• Bottlenecks in process workflows

Average Acknowledge Time (MTTA)

MTTA measures how long it takes a user to acknowledge an action after it is created.

If this value is high or shows “No data,” it may suggest:

• Users are not marking themselves as available

• Alerts are not being acknowledged promptly

• Processes for ownership might need review

• The site may be heavily relying on escalation

MTTA is a strong indicator of real-time responsiveness.

Number of Actions Created vs. Completed

This time-series graph shows daily counts of:

• Actions Created

• Actions Resolved

• Actions Ignored

• Actions Expired

This allows sites to quickly identify:

• Days with unusually high alert volume

• Backlogs building up

• Shifts where performance was better or worse

• Trends related to staffing, workload, or process instability

The comparison between creation and completion is key to understanding whether the team is keeping up with incoming alerts.

Most Common Profiles

This section displays a Pareto-style ranking of the profiles that generate the most actions.

This helps answer questions such as:

• Which profiles are triggering most frequently?

• Are certain rules too sensitive?

• Is there a recurring operational issue (e.g., repeated attrition spikes, cycle-time deviations)?

• Should some thresholds or windows be adjusted?

This is one of the most valuable sections for tuning profiles and improving the factory’s alerting strategy.

Longest Pending Actions (All Time)

This panel shows which actions have remained open the longest, including:

• The profile or module that triggered them

• How many days/hours they have been pending

These insights help identify:

• Actions that were forgotten or never addressed

• Rules that may be firing on noise or non-critical events

• Situations where responsibility or ownership might be unclear

• Cases where escalation paths may need adjustment

Long-pending actions often highlight opportunities for:

• Profile tuning

• Playbook improvement

• Better routing

• Additional training

Using the Filters

Since this dashboard operates in Grafana, all of the standard filtering capabilities are available:

• Select specific sites, areas, or lines

• Filter by module or profile

• Compare different time ranges (e.g., last 7 days vs. last 30 days)

• Drill down into specific production zones

• View only certain machine groups or shifts

This flexibility makes the Activity Feed ideal for:

• Daily production meetings

• Shift handovers

• Weekly performance reviews

• Root-cause analysis

• Identifying where Action Manager is delivering value

Glossary: Action Manager Training

• Action: Record created when a profile detects a qualifying event. Contains all data, routing info, dashboards, and playbook details.

• Action Manager: ArchFX’s engine for detecting anomalies, triggering alerts, routing events, and guiding teams through standardized responses.

• AI Summary: Automatically generated explanation based on KPIs, dashboards, trends, and historical data that highlights when/where the issue occurred and possible causes.

• Area: A section of the factory containing multiple lines or machines (e.g., SMT, AOI, Assembly).

• Assign To: Group designated to receive and handle an alert.

• Assignment Option: Defines if the alert goes to all members or is auto-assigned to one based on availability/workload.

• Availability: Indicates if a user is active and able to receive alerts.

• Dashboard Links (Screenshot / Live): Links to the specific dashboards relevant to the action; screenshot uses exact timestamp and live shows current data.

• Escalation: Automatic process that forwards unresolved actions to higher-level groups after a set period.

• Escalation Level: A step in the escalation chain with its own routing group and rules.

• Expired Action: Alert that was not acknowledged or resolved within the defined timeframe.

• Group: A set of users responsible for receiving and resolving certain alerts.

• Level: Aggregation level used for metrics (machine, line, area, site). Must never exceed the scope.

• Machine: Individual equipment unit being monitored.

• Module: Predefined logic package (Attrition, Cycle Time, Downtime, etc.) used to detect specific anomalies.

• MTTA (Mean Time to Acknowledge): Average time it takes users to acknowledge alerts.

• MTTR (Mean Time to Resolve): Average time it takes users to resolve alerts.

• Playbook: A site-defined document with steps, images, and instructions used to guide resolution of an issue.

• Playbook Collection: Folder containing multiple related playbooks.

• Priority: Importance level (1–5) assigned to an alert based on impact.

• Profile: A configuration of a module defining thresholds, windows, scopes, routing, and escalation.

• Profile Description: Name of the profile; recommended to include threshold + scope for clarity.

• Resolve: Closing an action after addressing the issue; should include comments on what was done.

• Scope: Where the rule applies (site, area, line, machine).

• Action Status: State of an action: Pending, Resolved, Ignored, Expired, Escalated.

• Profile Status: State of a profile: IN-SYNC, NOT-SYNC, DISABLED.

• Task: A single step inside a playbook.

• Trigger: Event that fires when conditions defined in a profile are met.

• Trigger Time: First and last moments when the profile detected the condition.

• Window: Time range used to evaluate the metric (e.g., last 60 minutes).

• Workload-Based Assignment: System auto-selects a user based on workload and availability.