| Term |
Definition |
| A |
| Action Item |
A unit of work required of a User; the smallest unit of a process, a single task. Instantiated based on information from an Action Item Definition. Ends up being a Data Entry Form (a To-Do Item) on somebody's To-Do list. May contain multiple Action Item Fields.
 Back to top |
| Attachment |
Arbitrary information that can be associated with a process instance whose format is not defined in the process definition. Generally functions just like attachments in email. The maximum size all attachments must total 7 Mb or less.
Back to top |
| B |
| C |
| Community |
An aggregation of users across nodes for the purpose of governing access to resources. [A group of users that have some reason to need the same resources. Could be based on current associations such as city or county emergency response teams.] This is part of the Trust Model. For example, if a user belongs to a community, they can a) instantiate a process that has been published to that community, and b) be trusted to use that resource. Communities are set up and managed using the Admin Tool.
Back to top |
| Community Role |
Roles are used to differentiate which community members have access to which resources. In a "real-life" community, there may be such Roles as emergency manager, fire chief, or special response teams. The duties of the role don't change even though different people may hold that role at different times. Persons holding such Roles usually have all the privileges granted to regular Members of the community plus those necessary to fulfill their Roles. When they leave the role, they leave those "extra" permissions behind as well. Our Communities work the same way. Permissions are assigned to a Role and the Member holding that Role can change. One or more people can be assigned to a single Role -- a Community can have one Role for all participants, for example. Roles can also used as recipients of Action Items, Notifications, and Escalations. If you specify a Community Role as an Action Item Receiver, every User assigned to that Role will receive that Action Item. Once the first User completes it, however, it disappears from every other Receiver's To-Do List.
Back to top |
| Completion Code |
A code that is generated to indicate that a process, step or activity is complete. Also indicates status of completion: successful, unsuccessful, etc. The list of available codes and how each one is to be handled is specified in Process Author. May be used to determine conditional process execution: next step, branch, loop and to fire off conditional notifications.
Back to top |
| D |
| Data Fields |
"Storage" locations for all data associated with a Process. The locations are defined (name and type of data), but not the actual data contained in them (which is entered by user interaction with a process requirement).
Back to top |
| E |
| Emergency Response Process |
A set of one or more linked procedures or activities which collectively realize an emergency response objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships. Often simply "Process".
Back to top |
| Entry Notification |
A notification that is sent at the beginning of a step (when that step is "entered"). Notifications do not affect the sending or time duration of Activities; for example, if the receiver of a Notification does not read it for two days, the recipients of that step's Action Items do not get an "extra" two days to accomplish their tasks.
Back to top |
| Escalation |
The process of notifying one or more people when a certain criterion is met, such as a task not being completed within a certain time-frame. ProEMPT supports two types of escalation-Organizational and Custom.
Back to top |
| Exit Condition |
Completion Codes ("Success", "Fail", etc.) are determined based on a condition evaluated at the end of a process or step. The Process author defines which condition generates which code.
Back to top |
| Exit Notification |
A notification that is sent at the completion of a step or process.
Back to top |
| Expiration |
After a certain amount of time elapses, a step or activity can expire. An expired item is considered completed and has a completion code of expired. An escalated item, on the other hand, remains open; it just goes from one recipient's To-Do List to the next recipient's To-Do List. Defined using Process Author.
Back to top |
| F |
| G |
| H |
| I |
| Input Attributes |
Parameters that define what data the View will accept as input.
Back to top |
| J |
| K |
| Key People |
The people responsible for specific roles in the current process, such as Primary Process Owner or Error Receiver. Specified on Activity, Step, and Process level, although if Step and Activity levels are not specified they will default to Process-level key people.
Back to top |
| L |
| M |
| Member |
If a User is assigned to any Role within a Community, that User is considered a Member of that Community.
Back to top |
| N |
| Node |
The smallest unit of functionality that can stand alone as a disconnected, independent installation of the ProEMPT system.
Back to top |
| Notification |
A message delivered via email or wireless device. The contents and recipients are defined using Process Author. Not to be confused with Escalations; escalations can also send Notifications, but may also reassign the Action Item itself.
Back to top |
| O |
| Organizational Escalation |
The default pattern of Escalation notices; the next Notification will be sent to the supervisor of the previous recipient as pre-defined in the Admin Tool.
Back to top |
| P |
| Permissions |
Permissions govern access to functionality. To log on to any of the applications or tools, or to perform almost all activities requires the correct permission for that activity. Permissions are administered via the Admin Tool.
Back to top |
| Primary Process Owner |
The Primary Process Owner has primary ownership and responsibility for the process's success or failure. If no one else is specified, the author of the process automatically becomes the Primary Process Owner.
Back to top |
| Process |
1. A step-by-step procedure that an emergency response team goes through to address a crisis situation
2. An emergency process as mapped out in Process Author, AKA a Process Map
Back to top |
| Process Author |
1. Desktop application used to map out Processes and publish them to Communities so that they can be launched. Graphical interface produces XML code in the background so process analysts and experts can write the processes, not programmers. 2. The person who authored a process.
Back to top |
| Process Map |
The graphical representation of a Process as viewed in Process Author. A process map contains not only the Process Definition, but also the metadata associated with how it appears within the Process Author tool.
Back to top |
| Process Role |
A role specific to a given Process Definition, which doesn't have anyone defined to it until a process instance is running. Used as a placeholder for Notification, Escalation, and Action Item receivers. (ProcRole data type) For example, a Process Role can be defined to be "the receiver of an Action Item in Step 2 of Emergency Response process #1" that placeholder will resolve to a UserID when an instance of the process is launched and after Step 2's Action Items have been received. Note that using the Process Role "the receiver of an Action Item in Step 2 of the process" in Step 1 will cause an exception, as the placeholder cannot be filled.
Back to top |
| ProEMPT |
ProEMPT . Catch-all phrase describing the entirety of ProEMPT Technology's platform and tools; includes the Database, Server-Side Engine/Main UI, Admin Tool, Process Author, Data Source Author and View Author.
Back to top |
| Published |
The publishing step associates a released resource with a community. After the publish step, the community has access to that resource - it shows up in the list of available resources.
Back to top |
| Q |
| R |
| Role |
See Community Role and Process Role.
Back to top |
| S |
| Save |
Store a copy of a resource for editing/finishing later. Saved items are not accessible by members of communities until published to those communities. Simply saving does not make them accessible.
Back to top |
| Server-Side Engine |
The middle-tier services which power the ProEMPT system. All backend connectivity to databases and other systems occurs through these services.
Back to top |
| T |
| To-Do List |
When a process is launched, the action item becomes a To-do item in the recipient's To-Do list. AKA Inbox.
Back to top |
| U |
| User |
A user is a person with a valid login id to the ProEMPT system on a particular node. The person has been added to the ProEMPT system by someone with admin permissions using the Admin Tool.
Back to top |
| User ID |
An identifier that uniquely identifies a user of the ProEMPT system on a given node.
Back to top |
| V |
| View |
A resource that can invoke a data source definition using any one of a variety of filters and present the results to the user.A snapshot of data in a database. A View is basically the display of information as retrieved by an SQL query. Views are created with View Author.
Back to top |
| View Author |
The View Author tool is a dynamic, web based application that provides a means for non-DBA users to maintain and edit "Views" of Process data via a pre-defined query in a collection of database tables and queries called a "Data Source". The View Author provides the ProEMPT system's reporting functionality.
Back to top |
| W |
| Web Application Server |
ProEMPT is a multi-tiered application. The Web Application Server communicates with the Server-Side Engine, which communicates with the database. This is where the ProEMPT Tools and support for the Web-based user interface are installed.
Back to top |
| Working day |
A day when it is expected that a particular emergency management process may be needed. A day that is to be considered when calculating durations when using the Calendar.
Back to top |
| X |
| Y |
| Z |
