Pulse User Guide

Pulse opens on the Dashboard. Across the top is the main menu, and it stays with you everywhere:

1. Dashboards - a menu of the live views: Unified Timeline (the Dashboard, several devices at once), Production Summary (a table or pivot you build yourself), Employee Punch Timeline (who was clocked on, next to what the machine was doing), Day at a Glance (one device's whole day, summarized), Andon (one big card per machine, built for a wall screen), and Edit log (every change made to production data).
2. Plan Realization - how actual production is tracking against plan.
3. Alerts - rules that watch your devices and notify the right people.
4. Reports - a menu of shift, production, and OEE reports.
5. Data Export - the raw rows behind everything else, filtered and downloaded as CSV, XLSX, or PDF.
6. Utility - extra tools: the Comparison Tool, and Open line display for putting Pulse on a screen at the line itself.
7. Settings - shift emails, downtime rules, anomaly detection, and more.

On the far right, a sun/moon button switches Pulse between light and dark - use whichever suits your screen and lighting. Everything in Pulse renders cleanly both ways.

The Dashboard is the Unified Production Dashboard - a live timeline of what your machines are doing. Pick one or more devices on the left and Pulse draws their production as horizontal bands across the day.

The filter panel (left). Top to bottom:

• Devices - check the machines you want to see. Use the search box or All to move quickly. (Tip: Only Show Data From Running Devices hides anything idle so a busy plant stays readable.)
• Hierarchy - narrow to a plant, area, or line instead of picking devices by hand.
• Time Filter - the window the timeline covers. Pick Shift (this shift, last shift, and so on), Time Range (an explicit start and end), or Relative - Last 12 Hours, Last 24 Hours, or Last 7 Days. A relative window can also Keep range rolling, so it re-anchors itself as time passes instead of freezing where you left it.
• Channels - which bands to draw: Scheduled Job, Job, Shift Hour, Shift, and Process State.
• Timeline metric - how the bands are colored (Efficiency, OEE, and so on), so good and bad time jump out at a glance.

Reading the timeline. Each selected device gets a stack of bands:

• Job - the part/job running, with its live efficiency and good vs. target counts right on the bar.
• Hour and Shift - the hour and shift the time falls in.
• State - the fine-grained machine state (running, down, changeover, and so on), color-coded.

Green is good, amber and red flag lost time. Hover any segment and the details panel on the right fills in with the exact numbers for that slice. Where operators were clocked on during that slice, the details panel also lists them by role - Primary, Secondary, Maintenance, and Other.

Where the running job is heading. While a job is still running, Pulse draws its bar out to a Predicted End and shows that time, and the predicted duration, in the details panel alongside Good / Goal and Pieces to Goal.

The forecast is worked out from the job's own goal count and the rate it is actually running at: the pieces still to make, multiplied by the time each one is currently taking. It needs nothing but the Job channel - there is no need to turn on Scheduled Job, and a job with no schedule behind it is forecast just the same. Progress counts the whole run, not just the part visible on screen, so a job that started before the window you are looking at is still forecast correctly.

Pulse would rather show you nothing than a number it cannot stand behind, so the prediction disappears when it would be guesswork: when the machine has stopped (something newer than the job has been recorded for it), when a later job or changeover already follows it, when the window you are looking at does not include right now, or when there is no usable goal or rate yet.

From a bar to the raw rows. Right-click any event on the timeline and pick Drill into a dataset - or use the Drill in button in the details panel - to open Data Export with that event's device and time window already filled in. It is the fastest way to get from "that bar looks wrong" to the records behind it.

Production Summary is a table you build yourself. Pick the devices and the time range on the left, decide what each row stands for, and Pulse adds up the production behind every row: counts, times, rates and OEE. Open it from Dashboards, then Production Summary.

It opens as a Hierarchical table of Device then Shift, with OEE, its three factors, good and reject counts, run time and down time, so there is something to read before you change anything.

Which view answers your question. The Grouping control sets the shape of the table:

• Aggregated - "How did each device do on each shift?" One row per combination of the row dimensions, nothing nested. The plainest table, and the best one to sort, trim to the worst few rows and export.
• Hierarchical - the same numbers as a tree with a subtotal at every level. "How did the line do, and which device or shift inside it is responsible?" Open only the levels you need.
• Pivot - "How did each shift do on each day?" One dimension runs across the columns, chosen in Columns by. Best for comparing the same thing across days or devices.
• Event list - keeps separate occurrences instead of combining them. One row per event of the first row dimension: a stretch of time on one device that shares that dimension's value, such as one job run, one shift or one production state. Newest first, with a Start time column. Use it to find the single odd event behind a number.

Building the table. The toolbar has a button for each part of the setup, and each one opens the same editor on its own tab. The number on a button counts what is set on it. Nothing changes on the page until you press Apply; closing the editor throws the changes away, and Apply stays off while something is invalid, with the reason written in the editor.

• Rows - the row dimensions. The order is the nesting: Device then Shift puts a Shift subtotal inside every Device, Shift then Device does the opposite. Use Add row dimension to add one, the arrows to reorder, and the remove control beside it to drop it. A dimension can be used once. Dimensions are grouped as Hierarchy (Enterprise down to Device, and Device type), Production (Shift, Team, Part, Job, Production state, State reason, Performance impact) and Date and time (Hour of shift, Hour of day, Date, Day of week, Week, Month, Quarter, Year). In a pivot this tab also holds the column dimension.
• Columns - the metric columns, in the order you want them. Search by name, browse by family, or add a Metric set such as OEE with factors or Production time detail to bring several at once. Use the arrows to reorder metrics or the remove control to drop one. You can also drag a metric header in the table to reorder it there. Dimension columns show a dimension next to each row without splitting the row by it; a row that spans several values shows Multiple (n). Pivots do not have them.
• Filters, Sort and Options are covered below.

Worked example: OEE by device and shift. You want to know which shifts are costing the most. On the left choose the devices and Last 7 Days. Set Grouping to Aggregated, and on Rows use Device then Shift. On Columns add the OEE with factors set plus Down time. Click the OEE header once so the lowest OEE comes first, and on Options set Top N rows to 10. The ten weakest device and shift combinations are on screen, and the total at the top still covers every row, not only those ten. Switch Grouping to Hierarchical when you want the same rows under a subtotal per device.

Worked example: shifts across days. To see whether one shift is consistently behind, choose Pivot, put Device then Shift on Rows, and pick Date in Columns by. Keep the metrics to one or two, usually OEE, because a pivot makes a column for every metric on every date. Each Device is a group you can open; its Shift rows carry one cell per day. A dash means there is no production data for that shift on that day; missing values sort last.

Filters. Two kinds of narrowing sit at different points, and the difference matters.

• The panel on the left - Devices, Hierarchy, the Time Filter and Only Show Data From Running Devices - is the same panel the Dashboard uses, so a selection made in either place is the selection in both. It decides what data exists for the table at all. Do not confuse the Time Filter with the Shift row dimension: one chooses the period, the other splits it.
• Dimension filters (editor, Filters tab) cut the data before it is added up. Pick a dimension, choose equals or does not equal, and tick the values. A filter with nothing ticked is inactive. Combine dimension filters decides whether All must match or At least one must match.
• Metric filters hide rows by their totals, after the adding up: for example OEE less than 60. Operators are is zero, is not zero, greater than, at least, less than and at most. Enter percentages as percentages (60 means 60%) and times as h:mm:ss. A metric filter works on a column in the table, so add the column first, and all metric filters must match. If you remove a column used by a metric filter, remove its filter too before you can Apply.

The line under the page title always spells out the active grouping and filters in words, and the same text heads every export.

Sorting. Click a column header to sort by it alone: the first click is ascending, the second descending, the third returns to the default order. Shift + click adds that column as a further rule, and the headers show rank numbers once two or more rules are active. The Sort tab lists the same rules, where you can reorder them, flip a direction or add one by name. Earlier rules win; later ones break ties.

Four rules keep a sorted table readable:

1. In a hierarchical table the parents rank by their own total, and the rows inside each parent sort among themselves. Children never jump out of their parent.
2. Empty values go last in both directions.
3. The total row stays pinned on top and is never sorted.
4. Rows that tie keep their natural order (dimension order, or oldest first in the event list), whatever the direction.

The total row and Top N. Totals puts a row on top of the table that stays in view while you scroll. Every total is worked out from the summed times and counts, never by averaging the rows beneath it, so the combined OEE, availability or reject rate of several devices is the true figure for those devices. A busy device counts for more than an idle one, as it should.

Top N rows keeps the first N rows after sorting, or the first N top-level groups in a hierarchy, together with everything inside them. It only trims what you see: the total row still covers every row the filters leave. Leave it empty to keep all rows.

Reading a cell. A percentage shows its number in bold above a bar scaled from 0 to 100. With Status colours on, the bar and number take the colour of the band the value falls in, using the thresholds from each device's metric alerts, the same bands the Dashboard uses. Colour is never the only signal:

• A small tick on the bar marks where the good band starts.
• Every band except good has an icon to the left of the number (Caution, Warning, Critical). Good has none: no icon means fine. Hover a cell for the band name.
• Status applies to OEE, Availability, Performance, Quality and Efficiency. Other metrics are plain numbers.

Two rules keep the colours honest. A cell with less than 10 minutes of production time has no colour, because short samples give misleading percentages. And a row that spans several devices is coloured only when every device's thresholds put its value in the same band; if they disagree, or a device has no thresholds, the cell stays uncoloured rather than picking one device's answer for all of them.

Opening and closing groups. In a hierarchical table, or a pivot, click anywhere on a parent row's label to open or close it. The arrow works as well, and so does dragging to select text without toggling. Expand to level opens the tree to the depth you pick (Show to Device, and so on) or Expand all.

Drill-through. Double-click a row to see the events behind it. Pulse switches to the Event list, filtered to that row's values and sorted newest first, and Back to summary returns you to the table you left. It works on the aggregated rows and on the innermost rows of a hierarchy, not on a group or total row and not in a pivot.

Saving a view. The Views menu saves the current table setup (rows, columns, filters, sort, options) under a name you choose, and loads it again later. The devices and time range are not part of a view: they come from the panel on the left. Saved views live in the browser you are using, under Saved on this browser, not on the server, so they do not follow you to another computer and are not shared with colleagues. Reset to default view brings back the opening table. Pulse also remembers the table you last built in that browser.

Exporting. The Export menu saves the table as it is on screen, as an XLSX (.xlsx), CSV or PDF file: same columns, same order, the total row first, every group included (even closed ones), each level indented. Above the table a header block records the devices, view, period, filters and active sort, so a file passed around still says what it is. The file name carries the view name and the date range.

The same menu has Raw production metrics, which opens Data Export on the underlying rows for the same devices, hierarchy and time range, for when a total needs checking record by record. It does not carry the view's own dimension filters; add those in Data Export.

Day at a Glance takes a single device and lays out its entire day in one view - the timeline, plus the summaries that turn it into a story.

Below the timeline you get, all for the same day:

• State Summary - the split of the day between Running, Down, and Meal/Break, as a single proportional bar.
• Cycle Summary - the same treatment for cycles: Run Cycles, Small Stops, and Partial Cycles, by the time each accounts for.
• Instant chart - the day plotted across time, so you can see exactly when things dipped. Chart Type picks what it plots: OEE, Good/Reject, Cycles, or Cycle Time.
• Two Pareto charts - lost time by reason, and number of occurrences by reason, so the biggest problems sort themselves to the top.

The Options on the left let you show or hide any of these and choose the chart type. There is no aggregation setting to get wrong: Pulse sizes the buckets to the width of the chart on your screen, so the shape stays readable whatever the window. Show Comments brings the day's notes in alongside the charts, and the Pareto charts can be narrowed with Include Unplanned Stop, Include Planned Stop, and Include Not Scheduled.

The Cycles chart type is the one worth knowing about. It stacks Run Cycles, Small Stops, Partial Cycles, and Slow Cycles across the day. Slow Cycles are the ones that completed but took longer than the ideal cycle time, which is exactly the loss that never shows up as downtime. Where Pulse has no slow-cycle figure for a period, the chart labels it Unclassified rather than counting it as good time.

Employee Punch Timeline (under Dashboards) answers the question the production timeline cannot: who was on the machine when that happened? It draws the same job, shift and state bands you already know, and adds a row per operator role underneath - Primary, Secondary, Maintenance, and Other - showing who was clocked on and for how long.

A few things worth knowing:

• Punches are independent of jobs. An operator who stays on through a job change reads as one continuous punch, not two.
• Where two people overlap in the same role, their punches stack into separate lanes rather than hiding one another.
• A punch with no clock-out yet runs to the current time, so an open shift looks open rather than looking like a gap.

The same names appear in the Dashboard's details panel under Employees, so you can also pick them up without leaving the timeline.

The Edit log lists every change made to production data, newest first within each device. Open it from Dashboards, then Edit log. Use it to answer "who changed that, and when?" for an event, a count, a job run, a split, a comment or a manual input.

Each row shows the Time stamp of the edit, the Item start time of the item it changed, the Type of item, its Duration, a short Info summary, the User who made the change, and the Change itself. The Timeline column has Open on timeline, which opens that item on the timeline.

Narrowing it down. Set From date and To date, and pick one Device or All devices. Times are shown in the time zone the page names. Rows that belong to the same edit are merged into one row, which shows how many rows it covers. An item that has been edited carries a marker with who edited it and when. If the editor is not known, the marker says so.

Comments are how Pulse captures the why behind the numbers - the note an operator leaves on a downtime, the context a supervisor adds to a rough shift. The Comments Report (under Reports) is where they all come together.

Comments are grouped into threads tied to what they're about - a job, a shift, a downtime event - and you can reply to build a conversation. On the left, the Event Types filter narrows to just the kinds of events you care about (Job, Shift, Downtime / Process State, Part, Team, and more), and the Time Filter picks the window by when the comment was written.

Across the top you can search the comment text, sort (most recent activity, and so on), and Export the set you're looking at.

Comment Analysis. The panel on the right reads the comments currently in view and tells you what is in them, so a few hundred notes become something you can act on. It works on exactly the set you have filtered to - it says how many comments that is - and nothing runs until you click Run analysis. Change a filter afterwards and it tells you the result is stale and offers to re-run.

Standard analysis runs entirely inside your own system, and gives you:

• Overview - how many comments were analyzed, and how many were blank.
• Sentiment - the split between positive, neutral and negative. Pulse labels this a rough lexical estimate rather than a precise measure of mood, and you should read it that way.
• Top terms and Top phrases - the words and word-pairs that keep coming up.
• Themes and Reason-code matches - recurring subjects, and where the wording lines up with your own downtime reason codes. Each theme carries how many comments it covers and quotes one of them, so you can see what the label actually means.
• By device, By event type and By author - who and what the comments cluster around.

AI mode is a second button next to Standard, and it answers a different question. Instead of counting words it reads the comments and writes back:

• a Summary in prose - what happened across this set of comments;
• Themes it found, described rather than tallied;
• Moods, which catch the tone that word-counting misses;
• Notable comments - the individual notes it thinks you should actually read.

Every AI result carries the line "Generated by AI from the comments in view", because it is a reading of your comments rather than a measurement of them. Treat it as a well-informed colleague's summary: quick, usually right about the shape of things, and worth checking against the comments themselves before you quote it.

A line display is Pulse on a screen bolted to the line itself, for the people running it. It shows that one line's timeline and one thing else: a comment box. There is no menu, no filter panel, no links, and nothing to click that would take the screen somewhere else. Whoever is standing in front of it can read what the line has been doing and explain a stop. That is the whole surface.

Opening one. From the Dashboard, pick the single device the screen belongs to, then choose Open line display under Utility. It opens in a new tab already pointed at that device. The address it opens is an ordinary Pulse address with kiosk=1 in it, so you can save it as the screen's home page, put it in a browser shortcut, or hand it to whoever sets the machine up.

One screen, one line. A line display shows exactly one device, and the device is named in the address. If the address names none or more than one, the screen says so and shows nothing else rather than guessing - a wall display quietly showing the wrong line is worse than one that tells you it is misconfigured.

Every screen looks the same. A line display ignores whatever filters that browser happens to have saved, and it never writes its own back. Two screens given the same style of address show the same thing, so a display does not slowly drift into a private layout because somebody once changed a filter on it. It also leaves your own saved filters alone if you open one from your own browser.

It keeps up on its own. Unless the address says otherwise, a line display shows a rolling twelve-hour window that advances by itself. Nobody has to touch the screen at shift change. If you do want a different window - a fixed shift, a specific range - the ordinary Dashboard time settings work in the address and override the default.

Comments. The strip along the bottom is always there. It is attached to the most recent state the machine was in, and names it: when it started, what state it was, and the downtime reason if there is one. An operator types what happened and presses the button, and it appears straight away. Clicking a different bar on the timeline moves the strip to that event, so a stop from earlier in the shift can be explained too.

These are ordinary Pulse comments. They show up in the Comments Report, in the Dashboard, and everywhere else comments appear - the line display is just a different way in.

The Andon board is every active machine on one screen, one big card each, built to be read from across the floor. Open it from Dashboards, then Andon. Machines that are reporting right now come first, and the cards update live as production comes in. V1, V2 and manual devices all appear together; a card says which kind it is, and says what that kind can report.

Colour tells you the state. Each card carries the colour of what the machine is doing, and it is the same colour the timelines use for that state:

1. Green - running.
2. Yellow - running slow. It still counts as running; it is a warning, not an alarm.
3. Amber - changeover or another planned stop.
4. Red - down on an unplanned stop. Only red counts as an alarm.
5. Blue - not scheduled. A blue card can carry a reason name such as Not monitored; the colour is what groups it.
6. Grey - no recent data, or a reason none of the above covers.

A legend above the cards counts the machines in each colour, and each card shows how long the machine has been in its current state.

Choose what each tile shows. Tile metrics lets you pick up to four figures per card: OEE, availability, performance, quality, efficiency (good count against target), output, and time in state. The first one you pick is drawn large. Ratios take their colour from the bands set on the device's alerts, so a figure turns amber, red or solid red as it drops. A device with no bands set gets no band colour: the large figure then takes the card's status colour (blue on a blue card, for example) and the smaller ones stay plain. The footer of each card can also show the job, part, shift and team.

Filter the board. Next to the family filter (V1, V2, manual) sits a Filter control: show only machines in certain status colours, or only those with OEE below a number you type. A machine whose OEE is not defined yet is never counted as below anything. Your choices are kept in the address and in your browser, so a bookmarked board comes back the way you left it.

Pace against target. A card compares the last hour's good count with its target (ahead, on pace, or behind, in your unit), the part's configured takt time with the average cycle time, and the whole run against the job's goal. It also raises a Reason needed flag when a machine is set up to ask for a reason and its stop is still sitting on Missing Reason. A card draws none of these for a machine that has no target, takt or goal, rather than showing an empty gauge.

Wall display. Wall display takes the board full screen and lays the cards out to fill a 1920 or 2560 screen; press Esc to leave it. Disable notifications keeps the alert banners off the screen while the board is up, so a TV in the break room is not covered by a pop-up.

A cutter counts sheets, a winder counts rolls, a packer counts pallets. Pulse can show each one in the unit that makes sense for it, and let each person see the number the way they think about it. Production data is never changed: the counts stay exactly as the machine reported them, and units only change how a number is shown.

My units. On the Andon page, My units sets your own preference for each unit type - for example pallets for counts, or feet for lengths. A supervisor who thinks in pallets sees pallets on the board and in the Unified Timeline's good-count tooltip; the operator at the cutter can keep sheets.

What a card shows. Pulse first decides what one machine count means for the machine, its native unit, and stops at the first that applies:

1. The unit of the route operation for the part now running. An operation unit always wins over a device unit.
2. The machine's own unit, set on the Devices tab. This is what machines without a route use, such as V1 and manual devices, and parts that have no route.
3. Plain pieces.

It then picks the unit to display, again stopping at the first that applies:

1. Your own My units choice for that type of unit.
2. The setting for the machine's plant.
3. The organization's default unit for that type.
4. The native unit, as above.

A conversion has to exist for any of the first three to apply. If Pulse has no way to get from the native unit to the one chosen, it shows the native unit instead.

Setting units up (administrators). Units on the Andon page opens the catalog:

1. Units - the units that exist. Lengths, weights and volumes convert by a fixed factor; counts such as sheets, rolls and pallets convert by equivalences you define.
2. Equivalences - for example, 1 pallet = 500 sheets. An equivalence can be limited to one part, because a pallet of one part rarely holds what a pallet of another does.
3. Devices - each machine's unit type (pieces, length, weight or volume), its native unit, and what one machine count is worth.
4. Plants - the unit shown for each type of unit in each plant, such as feet or meters.
5. Operations - a route operation can carry its own unit, and it wins over the machine's unit for that part.
6. Preview - try a conversion before you rely on it.

When sign-in is on, only administrators change the catalog; everyone still sets their own My units.

Plan Realization answers a single question: are we on track to hit the plan? It lines up actual production against the schedule so you can see, in the moment, whether a line is ahead, behind, or on pace - and react while the shift is still running rather than after it.

Alerts is how Pulse tells people when something needs attention - without anyone having to sit and watch a screen. Each alert is a rule that watches your devices for a condition and notifies the right people when it happens.

The list shows one row per rule. For each one you see:

• Alert - its name and what it watches, such as machine down too long, a metric crossing a threshold, or end of a shift.
• Status - Firing (in red) means the condition is active right now; Off means the rule is paused.
• Sends to - where the notification goes (for example, email - 2 recipients).

Use New alert to add a rule, Edit to change one, and the trash icon to remove it. The Activity tab at the top switches to a history of what has fired and when.

Building one. New alert opens a form written in plain language rather than as a settings page. You name it, then work down the sections in order:

• Which devices to watch.
• When this happens - the trigger. Five kinds: Time in a state (a device stays in a state past your limit), Board stops reporting (an active V2 Vorne board misses reports), Metric drops (OEE, Availability, Performance or Quality falls below a number), Shift change, and Scheduled time (a recurring time of day). Only when adds the optional extra conditions.

Board stops reporting is available when the client has enabled the board-offline alert feature. Its timer starts after the first failed collector poll, and a healthy poll clears the alert. It covers active V2 Vorne boards; it does not detect a collector that has stopped completely, which requires separate heartbeat data.

• Message - what recipients receive.
• Recipients - who gets it.
• Channels - how it reaches them. Advertised send methods deliver today: Email, SMS, Microsoft Teams, Slack, Push, and an in-app banner inside Pulse itself. Pick the channel that matches how each recipient actually watches the floor.
• How often - fire once, or repeat every so many minutes while the condition holds.

Which devices is worth a moment. You can watch every device, or watch a level of your hierarchy - all plants, or a named set of lines - so a machine added next month is covered by the rule you wrote today without anyone remembering to come back. Except these devices takes the stragglers back out.

The Advanced switch at the top of the form adds the rest: any/all grouping of conditions, per-channel options, time windows, and the all-clear notice that follows up when a condition clears.

Sending alerts to Microsoft Teams. Pick one or more Teams channels for a rule and the alert lands in them as well as in anyone's inbox. The channels come from a registry you maintain once, under Alerts on the Channels tab, rather than being retyped into every rule - so if no channels are offered yet, that is where to add the first one. If a channel a rule was using is later deleted from the registry, Pulse tells you on the rule rather than quietly dropping the delivery.

Teams retired its classic Incoming Webhook connector in May 2026, so a channel is registered with a Workflows webhook URL instead. The Channels tab links a walkthrough for getting one.

Anomalies lists the unusual results Pulse's automatic detector has found: unplanned downtime far above what a device normally shows for that shift, and shifts that did not run at all. Open it from Settings, then Anomalies. How the detector runs is set under Anomaly Detection in the same menu.

Reading a row. Each anomaly gives the Plant, Device, Date, Shift, Metric, its Value, the Normal it is compared with, and How extreme it is. The normal is worked out from the device's earlier shifts, and the page shows how many shifts it uses. A plant-level note reads Whole plant with the number of devices flagged together.

Use Plant, Device, Start date and End date to narrow the list.

Checking the results can be trusted. The page says how many devices were checked and how many shifts were skipped, and why: not enough history, quarantined for data quality, no time zone, or too short or too little scheduled time. If the last detector run failed, or has not run for more than two hours, a warning says the results may be out of date. If the detector has never run, the page says that too. When nothing is flagged, the page says so for the shifts it checked.

The Reports menu holds Pulse's structured, printable reports. Most share the same left-hand filters - Devices, Shifts, a Time Filter, and an Export button - and each one answers a different question. They fall into three families: OEE reports, production reports, and the loss/recap reports.

OEE reports - how efficiently are we running?

• Shift OEE is the full breakdown for a shift: the three OEE components (Availability, Performance, Quality) and the combined OEE %, the split of the shift's time (Run, Unplanned Stop, Planned Stop, Not Scheduled), productivity counts, a 7-day OEE trend, and the shift's biggest lost-time events.
• Shift OEE Status shows those same shift numbers in an at-a-glance layout - a large OEE % front and center with Availability / Performance / Quality beside it, plus a Last Week vs. This Week comparison. Built for a quick "how's this shift doing?" read rather than deep analysis.
• Line OEE rolls the same OEE picture up to a whole line (every device on it) over a date range, so you can judge a line's overall performance instead of one machine.
• Line OEE Status is the line-level at-a-glance version - the production-time and performance summary for the line.
• OEE Waterfall takes the same numbers and walks them downhill: a waterfall chart from total time down to OEE, with a bar for each reason code that took a bite out of it, plus the headline figures and a summary underneath. It answers "where did the rest of the time go?" in one picture. It builds a snapshot from your current filters and tells you when the snapshot is behind them, so refresh it after changing a filter.

Production reports - what did we actually make?

• Shift Production is the detailed production report for the device(s) you pick, broken out shift by shift: good and reject counts, the output, and the run / stop time behind them. It answers "what did this shift produce?"
• All Shift Production is the plant-wide version - every shift's production across your time range in a single rollup. Pick Shift Only for a compact summary or full detail for everything. Because it can span many pages, Pulse asks before drawing a very large one. Use it to compare output across all shifts at once.

Loss and recap reports.

• Shift Summary is a one-page recap of a single shift: a Target-vs-Actual table (good / reject counts, efficiency, and the OEE components), the production-time split, and the top unplanned-stop reasons. The quickest "how did that shift go?" read.
• Top Losses ranks the biggest sources of lost time side by side across day, week, and month, so chronic problems stand out from one-off bad days.
• The Comments Report (covered earlier under Comments) pulls together every note your team left on jobs, shifts, and downtime.

Put your OEE target on the report.

Every report that draws a 7-day OEE trend can draw your OEE target on it too: a dashed line at the target, and each day's OEE as a bar - green where the day met the target, red where it missed. A day that hit the number exactly counts as meeting it, and a day with no production at all draws no bar rather than a red one.

Open Options on the report and set Target - OEE as a percentage. 70 means 70%. On Shift Summary the OEE target is the one already in its target values, so the recap table and the chart always agree.

The box starts empty, and empty does not mean no target. Pulse falls back to the company-wide OEE figure in Configurator's Metric Targets - the same one Explorer's charts read - and shows it greyed out in the box so you can see what the chart will draw. So a report can arrive with a target line already on it, without anyone typing anything.

What you type is an override for the report in front of you, not a separate setting: it replaces the company number on this report and nowhere else. Clear the box, or set it to 0, and the company target takes over again rather than the line disappearing. Whether higher or lower counts as better always comes from the company target, never from the number you typed.

Reports answer the questions Pulse already knows how to ask. Data Export is for the ones it doesn't: it puts the raw records on screen, lets you filter and arrange them however you need, and hands them over as a file. It is the right tool for a one-off analysis in a spreadsheet, for handing data to somebody else's system, and for checking what really sat behind a number you don't believe.

Four datasets, each on the Data Export menu:

• Metrics - the production metrics behind the timeline and every OEE report: counts, targets, run and lost time, per device, shift, job and state. Start here.
• Rejects - reject records, by reason.
• Job Punches - who was clocked on to what, and when.
• Instants - the raw snapshot stream. This one is enormous, so it arrives with a row limit already set.

Narrowing it down. The left rail carries the filters you already know from the Dashboard - Devices, Hierarchy and the Time Filter - followed by the ones that belong to the dataset in front of you: Shift, Shift Hour, Job, Part, Team, State, Reason, Reject Reason, Employee. The job filter searches rather than making you scroll. Above the table, a single Search box matches across every column at once.

The table pages and sorts as you would expect, and the page's address carries your filters, so a view worth keeping is worth bookmarking or pasting to a colleague.

Choosing columns. Every dataset opens with a sensible default set. Under Columns you can add, remove and reorder them - the order in the selected list is the order they appear in the file - and Reset to default columns puts it all back.

Two extra groups are there when you need them and out of the way when you don't: Include hidden Vorne fields and Include hidden IntelliSuite IDs. They add the raw identifiers and source fields that matter when you are reconciling against another system, and matter to nobody else.

Getting the file. Pick a Format - CSV, Excel (an .xlsx file) or PDF - and press Export.

• Excel is the one to choose for analysis, and the only sensible choice for a wide table.
• PDF is for sending someone a fixed document. A wide table has to be split into repeated column bands to fit the page, so Pulse warns you first and suggests Excel (XLSX) instead. PDFs are also built one at a time, so a large one may wait behind somebody else's.
• Every export stops at the Row limit shown on the page, and the server will not go past 100,000 rows whatever you ask for. The note under the table says so plainly: if more rows match your filters, the file stops at the limit and is not the complete result set. Tighten the filters rather than trusting the first 100,000 rows.

The Comparison Tool (under Utility) puts two or more devices - or two time periods - side by side, so you can answer "which line is doing better, and where's the gap?" without flipping between dashboards.

The Settings menu is where Pulse is configured - mostly a one-time or occasional job for a supervisor or admin. These pages decide who gets told what, and when, and feed the rules you see under Alerts.

• Shift Emails - automatic shift-summary emails: who receives them and for which shifts.
• Master Downtimes - email rules tied to downtime events, so the right people hear when a machine goes down for the wrong reason.
• Notification Rules - the powerful one: build custom rules that fire on specific events (a state, a reason, a threshold) and route a notification to the right place. Add and edit rules as your floor's needs change.
• Notification Settings - the admin page tying notifications and email together (channels, defaults).
• Anomaly Detection - settings for Pulse's automatic spotting of unusual production patterns.
• Bulk Edit - make the same change across many records at once, instead of editing them one by one.

Pulse renders cleanly in both light and dark - use the sun/moon button in the top-right to switch. The same Dashboard, two looks: