Central Help file

Adaptive Service Management: Overview


  • How does it work?
  • Definitions used by ASM
  • Alerts Definition and Lifetime
  • ASM Preconditions
  • Important Remarks and How-to's
  • Adaptive Service ManagementTM (ASM) stands for a set of tools and services that collect machine reported consumable levels and printer error states and triggers alerts based on dealer defined thresholds.

    How does it work? ASM collects consumable and printer error states information from local devices, deciphering the entire supplies section. Consumable items include toner, ink, wax, gel, maintenance kits, drums, transfer belts, fuser kits, or any consumable item a device is capable of reporting. Printer error states define a combination of states of a printer at the time it is audited. the states may refer to the device, supplies, paper or trays. Subsequent alerts are uniquely identified and further filtered using customizable dealer defined parameters. Once an alert is triggered, one or more simultaneous or follow-up actions are performed, accommodating the most complex dealer specific workflows. For example, when the remaining level in a cyan toner cartridge falls below a dealer defined threshold, an email may be sent to the dealers' service department, informing them a replacement is required. Upon approval a second email may be sent to the dealers' supplies vendor and simultaneously a purchase order may be submitted into the dealers' ERP system. For added flexibility and to reduce the number of interactions a dealer must make to manage the system, alerts may be pooled within a given time frame and/or actions may be performed automatically with no intervention required. The dealers' service department is provided with a dashboard and robust views of the current alerts, with drill-down reporting.

    The following schema gives a global overview of the system. Onsite collects the consumable information and sends it to Central to process it using User Defined Rules [and SBS Meta-information] to trigger and process consumable alerts.



    Definitions used by ASM

    Consumable Alert Definition - a set of configurations that define which Dealer owns the alert, to which accounts the alert applies, what consumable type is targeted for analysis, what consumable level triggers an alert, when does the alert become overdue or stale (the data is too old to be considered), what devices should be filtered for the alert to be applied, what resolution is proposed, what actions to be performed when the alert triggers or becomes overdue, and any additional information that might help the user act. Any Consumable Alert Definition can be configured with several Alert Filters that should be defined in a top-down approach using logical operators;

    Service Alert Definition - a set of configurations that define which Dealer owns the alert, to which accounts the alert applies, what printer error state(s) trigger an alert, when does the alert become overdue or stale (the data is too old to be considered), what devices should be filtered for the alert to be applied, what resolution is proposed, what actions to be performed when the alert triggers or becomes overdue, and any additional information that might help the user act. Any Service Alert Definition can be configured with several Alert Filters that should be defined in a top-down approach using logical operators;

    Action Definition - defines the type of action to be invoked when an alert is triggered or becomes overdue. It carries global configuration data as the default Number of Retries, whether it requires approval or not, if it was approved or not, or if it was performed or not, plus the information that identifies the type: Requires ApprRequires Approval and Overdue Action. The Ordinal of the action identifies the position on the Alert list of Actions , e.g. the first, the second, etc. The action definitions can be configured to take place simultaneously or as an escalation to the first action, in this case defining an workflow. Several Action Definitions can be configured for the same Alert Definitions. Each action can be configured to require approval or not, and for each action One can customize the style9">Action Processing Behavior or the Approval Email Processing Behavior, in the same way the Dealer can customize the Alerts Processing Behavior

    Alert Event - carry detailed information resulted when alert definition are applied to pairs of devices and triggers types. An alert event is uniquely identified by the alert definition, the device and, according to the alert tyep, the consumable type or the printer error state that triggered the alert; additionally, it contains information of when the alert triggered the first and last time, which were the consumable levels or error states in both situations and the status information that helps identify if the alert is overdue, ignored or archived

    Action Event - carry detailed information resulted when action definitions are applied to alert events. Action events are invoked on a timeline resulted from the configuration of the alert definitions that produced an alert event: Non-Approval actions are invoked when the alert triggers the first time, Requires Approval actions are actions are invoked after the user approves them, Non-Overdue actions are invoked at the same time with the first action, while the Overdue Action actions are invoked after the Overdue time has elapsed, counting from the moment the alert was firstly triggered or approved. The action events are used to determine the Alert Status of an alert event, as described in ASM Glossary.

    Primary Account Contact - the contact information associated to an account; usually describes the user credentials the account needs to log into Central;

    Account Alternate Contact - additional contacts of an account; they can additionally be used for logging-in purposes;

    Primary Dealer Contact - a dealer contact that has a specific meaning, as follows: Admin, Support, Service, Supplies and Billing Contacts. Usually, these contacts are mapped to dealer account existing contacts;

    Dealer Admin - the primary dealer contact of type Admin;

    Dealer Alternate Contact - additional contacts of the dealer account;

    Alerts Processing Behavior - a set of configurations uniquely identified by the Dealer and the Action Result Type (as defined in ASM Glossary). These configurations describe how each type of action should be performed and who should receive the results; e.g. the actions whose result is an email, might be configured in Alerts Processing Behavior page to send the email to one of the following contacts: One of the Primary Dealer Contacts, One of the Dealer Alternate Contacts, Primary Account Contact, One of the Alternate Account Contacts, or to a Custom Email  Recipient.


    Alerts Definition and Lifetime

  • Dealers or Administrators create and e create and edit Alert Definitions in the Define Alert(s) page;

  • Consumable Alert Definitions are defined for a specific Consumable Type and a Alert Threshold (Min) combinations as parameters. Consumable Types can be Toner, Ink, Wax, Fuser, Transfer or Custom Consumable filter;

  • Service Alert Definitions are defined for specific Printer Error State(s) and a Console Message combinations as parameters. Ptinter Error States may refer to Device, Supply, Paper or Trays;

  • Overdue and Stale intervals are configured from a list of possible interval types and using custom values;

  • Several Filters can be used to filter devices. The filters use a hierarchical approach similar to the Sync Modules and employ a top-down approach. The values that are fed into the top are filtered first by Managed vs. Non-Managed and further by Filter Method and finally the Value. Several methods are available to filter devices by: All, Contract type, Contract, manufacturer, Model family, Custom Model, Model, Account, Group, Daily Average Volume, Monthly Average Volume. Several filters can be defined for the same action, using logical operators as: AND, OR, AND NOT. These operators use a top-down approach, being respected a linear precedence: this means that the filters are grouped using subsequent operators, and every time subsequent operators are different, a new group is created (e.g. let us name the subsequent Filters 1...n as F1, F2...Fn. for the following example, F1 AND F2 OR F3 OR F4 OR F5 AND NOT F6, we have the following precedence execution groups: (F1) AND (F2 OR F3 OR F4 OR F5) AND NOT (F6) );

  • Each Alert Definition might trigger one or more actions. At least one action is required to complete the Alert Definition settings, however, additional actions may be configured and invoked either simultaneous to the first action, or as an escalation based on the Time Elapsed has exceeded the Overdue Alert value. The first action can either Do Not Require Approval or Requires Approval while the subsequent actions, besides the Approval flag, can either run Immediately (No-Overdue) or whe the Overdue time elapsed. The actions defined for an Alert Definition are designated as Action Definitions;

  • Alert Definitions can be Dealer Hierarchical or Non-Hierarchical. Non-Hierarchical alerts only apply to the selected Dealer Account, while the Hierarchical consider all Accounts in the selected Dealer Hierarchy;

  • ASM uses a scheduler that controls the background Alerts processing tasks, called ASM Scheduler;

  • Once the ConsOnce the Alert Definitions have been defined, each time the ASM Scheduler performs, the consumable levels or printer error states are verified against each alert definition that apply to a specific device and trigger types. If there are consumables with levels lower than the selected alert definition thresholds or devices with the triuggering error states, ASM Scheduler creates new instances of Alert Events, one for each Device and Consumable Type/Service Error State combinations;

  • Once the Alert  Events have been created, the ASM core looks for the Action Definitions to be performed for the triggered Alert Definitions. For each pair Alert Definition - Alert Event is created a new entry called Action Event. The Action Event is then used by ASM to track the evolution of the actions workflow associated with each Alert Event;

  • ASM Scheduler runs at configurable time intervals and processes the active Alert Events for each account in the database. The status of each alert is updated accordingly, based on the status of the action events that have been previously processed and on the time elapsed since the Alert Event was triggered;

  • When all Action Events associated to an Alert Event have been processed (e.g. Emails or Xml streams were sent) or the consumable level that triggered the Alert became higher than the Alert Threshold, the Alert Event is Archived. . IThe same happens when the triggering Printer Error States are no longer active for the device that triggered alerts. The Alert Event is also archived after the Stale Period has elapsed or as a result of a manual intervention that modified the parameters of the Alert Definition that originated the Alert Event. Alert Events might have different Alert Status, according to several factors that involve the actions that have been already performed, if they require approval or not, the consumable levels or the time elapsed since the alert first triggered, etc. 


  • ASM Preconditions

    To work properly, ASM requires that the following configurations are performed before you proceed to
    Define Alert(s)s:

  • The Administrator of Central must have configured a Valid Email address for the Primary Account Contact of the Main Dealer;

  • The ASM Email Templates have to be properly configured; they can be accessed under the Dealer Information -> Email Templates menu in Central main page;

  • SMTP has to be enabled in Central, under Tool Kit -> Server Configuration menu in in Central main page;

  • Primary Dealer Contacts and Primary Account Contacts have to be properly configured for each dealer in Central;

  • Each Dealer has to configure the Alerts Processing Behavior before proceeding to Define Alert(s)s;

  • It is recommended to configure the Calculated Values task to run on a hourly basis if you intend to Define Alert(s)s that filter the devices based on a Daily or Monthly Average Volume filtering methods;



  • Important Remarks and How-to's

  • Hierarchical & Non-Hierarchical Alert Definitions apply to an Account as follows:

  • Only the Hierarchical Alert Definitions of the Parent Dealers in Hierarchy, if the Children Account is Not a Dealer;

  • The Hierarchical Alert Definitions of the Parent Dealers in Hierarchy and All Alert Definitions Owned, if the Children Account is a Dealer;

  • Only the Hierarchical Alert Definitions of the Main Dealer, if the Account is Not a Dealer and is Orphan (has No Parent);

  • All Alert Definitions Owned, if the Account is a Dealer and has No Parent.

  • ASM uses Personalization that give users access only to the allowed accounts, as defined under the Account Visibility -> Data Visibility tab in Central main page;

  • Whenever a CoWhenever a Alert Definition is Updated, if any of the critical parameters that identify the Alert Definition or any of the related Action Definitions are changed, in this case, all related Events triggered aretriggered are Archived. As a result, new Alert Events will be triggered for the newly modified Alert Definition. A Advanced ASM configuration allows the administrators to disable Alerts Archiving when Alert Definitions are changed, but the effects of ongoing workflows may not always be predicted;

  • For an Alert Definition with a Stale TLarge Stale Time, if the consumable is replaced meanwhile, ASM detects it and archives the Alert events for that consumable. If the consumable goes below a predefined alert level shortly after it was replaced, a new alert triggers and a new alert event is created and processed by ASM. A similar behavior happens when the Printer Error States that triggered a Service Alert are no longer active on the device;

  • Invalid Recipient onsiderations5">Emails: ASM Actions of type Email that cannot identify any Valid Email Recipient, are Redirected to Dealer Admin;

  • Failed Emails: Emails that fail to be sent are Redirected to Dealer Admin. Dealers and Administrators can access the Email History page and check which emails were redirected;

  • Alerts Frequency affects overall ASM functionality by limiting the amount of actions to be invoked each time alerts are processed. When frequencies are specified, after the user Approves Alerts, the actions will be invoked only after the frequency interval has elapsed from the last time the same type of actions have been invoked for the same account. Default behavior when no frequencies are applied is that the alerts are invoked When triggered.

  • Consumable Part Cost column included in ASM reports and emails represents the custom consumable cost specified in the ASM Global Admin Settings page, section Consumable Costs Settings. The values specified in this section can be pulled from either Dealer Specific Values or Supplier Specific Values Parts & Service pages. The administrator can specify what default costs should be used for all accounts devices, or can prioritize suppliers to be used to check for first available cost or the lowest cost. Note that Dealer Costs refer to the first Parent Dealer in the Account Hierarchy.

  • How to avoid being inundated with emails: Configure larger intervals for Alerts Frequency option for each action type in Alerts Processing Behavior page.

  • Avoid using Orphan Accounts as they can only be monitored by Alerts defined for the Central Main Dealer only;


  • Copyright 2Copyright 2011 FMAudit, LLC.  All Rights Reserved.