ServiceWise Admin Guide. Date:

Transcription

1 ServiceWise Admin Guide Author: TechExcel co.ltd Date:

2 Table of Content ServiceWise Admin Guide Chapter 1 ServiceWise Concepts 1 Chapter 1-- ServiceWise Concepts 1.1 Understanding ServiceWise ServiceWise Projects Base Projects Subproject Management 1.2 ServiceWise Administration System-level Administration Project-level Administration Administrative Accounts and Access Controls 1.3 Team Representation and Management Account types Team groups Group folders 1.4 Incident and Event Management Incident Management Incident Workflow Incident Escalations Incident Routing Incident Escalation Events in views Event Management 1.5 Employee Management Employee Web Portal Tracking Web Conversations CTI Integration 1.6 Knowledge Management and Communication TechExcel KnowledgeWise Incident Knowledge Management Automatic Knowledge Suggestion 1.7 Asset Management TechExcel AssetWise Asset Inventory Management LANDesk and Microsoft SMS Integration TechExcel AssetWise Discovery 1.8 Professional Services Management Service Agreement Management Professional Services Management 1.9 ServiceWise Add-On Modules TechExcel ServiceWise LinkPlus Chapter 2 System-Level Administration 2 Chapter 2 -- System-Level Administration 2.1 Understanding System-Level Administration 2.2 Administering ServiceWise Projects at the System Level Creating ServiceWise Base Projects Creating New Work Projects Copying ServiceWise Project Settings Understanding Active and Inactive Projects Active projects Inactive projects Backing Up ServiceWise Projects Restoring Backed Up Projects Creating Projects Based from Backed Up Projects Deleting ServiceWise Projects 2.3 Managing Solution Templates Installing Solution Templates Viewing Solution Template Notes Updating the Solution Template Configuration Document 2.4 Running the Go Live Wizard Chapter 3 System-Level User Administration 3 Chapter 3 -- System-Level User Administration 3.1 Administering User Accounts at the System Level Understanding the Support Member Manager Support Member Manager controls Creating and Editing User Accounts Defining General User Data Defining User Administrative Access Controls Deleting User Accounts Defining User Profiles ing the ServiceWise Installer to Project Members Managing User Licenses 3.2 Defining Team Member Contact Information Defining User Autologin Settings Defining User Pager Service Information Defining User Mobile Service Information Defining User Account Signatures Page 2 of 145

3 3.3 Importing and Exporting User Accounts Importing User Accounts from Structured Text Files Importing User Accounts from a LDAP Server Filtering User Accounts in the LDAP Import Wizard 3.4 Administering System Team Groups Creating System Team Groups Assigning Users System Team Groups 3.5 Administering User Logins 3.6 Administering User Licensing Loading ServiceWise Licenses 3.7 Managing Administrator Account Types and Access Controls Creating System Administrator Account Types Chapter 4 System-Level Tool Administration 4 Chapter 4 -- System-Level Tool Administration 4.1 Administering the ServiceWise Document Server Configuring the ServiceWise Document Server Viewing the Document Root Directory Configuring Web Server Access to the Document Server Configuring Client Access to the Document Server 4.2 Administering Error Handling Defining General Error Tracking Settings Creating Log Files Define Service Messages Defining Service Error Reports 4.3 Administering LinkPlus Integration 4.4 Administering System Messages Defining System Welcome Messages Defining System Warning Messages Managing User Sessions 4.5 Administering System Time Zones and Time and Date Formats Defining Date and Time Formats Defining System Daylight Savings Settings 4.6 Administering CTI Integration Installing and Configuring CDC for ServiceWise Integration System-Level Integration Configuration Enabling CTI Integration Enabling and Defining Keyboard Shortcuts for Outgoing Calls 4.7 Administering the TechExcel Search Engine Installing the TechExcel Search Engine Configuring Search Engine Settings Indexing Multiple-selection List Controls 4.8 Managing ServiceWise Admin Reports Chapter 5 Project-Level Project Administration 5 Chapter 5 -- Project-Level Project Administration 5.1 Understanding Project Administration Project definition Incident definition and GUI customization Project member administration Workflow administration 5.2 Managing Project Properties Updating Project Names Updating Project ID Prefixes Making Projects Active or Inactive Enabling Web Uploading Enabling the Employee Web Portal Support Knowledge Building in ServiceWise Web Enabling Web Conversions Defining the Display Format of Names Defining Incident Description Field Sizes Defining Project Time Zones Defining Date and Time Formats Date Formats Time Formats Managing ServiceWise Windows Client Sessions Defining List View Refresh Options Defining Employee Quick Search Settings Defining Incident Quick Search Settings 5.3 Managing Optional Project Features Enabling or Disabling Optional Features Understanding Optional Features 5.4 Managing Project Administrators Adding and Removing Project Administrators 5.5 Managing Account Types Understanding Account Types Account types and privileges Account types and workflow Account types and project security Understanding Light Account Types Creating Account Types Editing Account Types Deleting Account Types 5.6 Managing Account Access Controls Chapter 6 Incident Administration Page 3 of

4 6 Chapter 6 -- Incident Administration 6.1 Understanding Support Incident Administration Understanding Support Incidents Understanding Incident View GUI Customization Understanding System Controls and Custom Controls 6.2 Configuring General Support Incident Properties Renaming Support Incidents Defining the Status Control as Read-only Enabling Co-owner Events Configuring Employee Access to Support Incidents 6.3 Administering Controls Administering System Controls Administering Custom Controls Understanding Control Types Understanding Control Customization Options Defining Control Labels Defining the Control Type of Custom Controls Defining Team Member Access Rules Defining Employee Access Rules Defining Options in Selection List Controls Defining Parent-Child Relationships Between Controls Customizing Autogrow Combo Box Controls Customizing Combo Box Controls Customizing Dropdown List Controls Ordering Options in Selection List Controls Customizing Multiple Selection Controls Customizing Data Grid Controls Customizing Single-line Text Box Controls Customizing Multiple-line Text Box Controls Enabling Multiple-line Text Box Time Stamping Customizing Check Box Controls Customizing Date-Time Controls Defining Team Member Access Rules Defining Employee Access Rules 6.4 Administering System Pages Customizing the Incident Detail Panel Adding the Link Page to the Incident Detail Panel Customizing the New Incident Manager Managing the Incident List Window Indicators Customizing the Description System Page Customizing the Current Status Page Customizing the History Page 6.5 Administering Custom Pages Adding and Removing Controls to Custom Pages 6.6 Administering Function Pages Chapter 7 Advanced Incident Administration 7 Chapter 7-- Advanced Incident Administration 7.1 Administering Incident Linking Understanding Incident Linking Defining Referential Link Types Defining Parent-Child Link Types 7.2 Managing the Web Conversation Page 7.3 Administering Incident Workflow State Display Order 7.4 Managing Incident Priority Understanding the Incident Prioritization Page Enabling Incident Prioritization Defining Priority Value Management Incident property definitions Incident time factors Granting Incident Prioritization Access Controls 7.5 Administering the Change Log Chapter 8 Interproject Copying and Linking 8 Chapter 8 -- Interproject Copying and Linking 8.1 Understanding Interproject Copying and Linking Administrating Standard Interproject Actions and Linking 8.2 Enabling and Configuring Interproject Copying and Linking Enabling Target Projects Enabling Interproject Copying Enabling Interproject Linking Enabling Workflow State Editing Enabling Incident Owner Editing Defining Default Owners in Target Project Work Description Editing Rules Title and Description Editing Rules Defining Concatenated Incident Title Prefixes Defining Default Account Type Access Rules Defining Default Subprojects 8.3 Mapping Incident Property Fields Manually Mapping Incident Fields Automatically Mapping Incident Fields Defining Mapped Field Choices Defining Default Field Values for Unmapped Fields 8.4 Administering Linked Issue Employee Web Portal Settings Displaying Linked Issue Info in the Employee Web Portal Page 4 of 145

5 8.4.2 Displaying Linked Issue Info in the Web Conversation Page Defining Applicable Incident Workflow States Defining Applicable Link Types Defining Title for Linked Issue Data Adding Linked Issue Information Fields Chapter 9 Incident Workflow Administration 9 Chapter 9 -- Incident Workflow Administration 9.1 Understanding ServiceWise Project Workflow 9.2 Administering Incident Workflow Defining the Project Workflow Model New Section Creating, Editing, and Deleting Workflow States Defining Applicable Owner Workflow Rules Action Performer Default Owner Rules Defining Incident Access ("Who Can Change" Workflow Rules) Defining Read-Only Field Workflow Rules Defining Invisible Field Workflow Rules Defining the Mandatory Field Workflow Rules Defining Default Submission States Enabling Closed Event Restriction 9.3 Designing ServiceWise Graphical Workflow Understanding Workflow Design Flowcharts Adding and Editing State Nodes Deleting Workflow State Nodes Creating and Editing Transition Lines Understanding the Graph Properties Manager Customizing State Nodes Customizing Transition Lines Magnifying and Reducing Workflow Flowcharts Saving Workflow Flowcharts 9.4 Administering Incident Routing Enabling Incident Routing Mandating Team Member Availability Incident Routing Understanding Incident Routing Rule Criteria Defining Workload Based Incident Routing Rules Defining Skill-Level Based Incident Routing Rules Defining Formula-Based Incident Routing Rules Defining Incident Routing Rules Chapter 10 Subproject Administration 10 Chapter10 -- Subproject Administration 10.1 Understanding Subprojects Administering Subprojects 10.2 Defining General Subproject Settings Customizing Subproject Terminology Enabling Subprojects in Work Projects Enabling Employee Assignment to Subprojects Enabling Subproject Applicable Owner Controls Restricting Incident Ownership to Subproject Members Restricting Event Ownership to Subproject Members Enabling Subproject Workflow Controls Enabling Subproject Cost Budgets Controls Defining Default Subprojects 10.3 Administering Subproject Status Definitions Understanding Subproject Status Criteria Defining Independent Subproject Status Settings Defining Derived from Highest Ranked Incident Status Settings Defining Derived from Lowest Ranked Incident Status Settings Defining Linked to Incident Status Settings 10.4 Defining Subproject Priorities Understanding Subproject Priority Criteria Defining Independent Subproject Priority Settings Defining Derived from Highest Ranked Incident Priority Settings Defining Derived from Lowest Ranked Incident Priority Settings Defining Linked to Incident Priority Settings 10.5 Defining Subproject Access Controls Chapter 11 Integration Administration 11 Chapter11-- Integration Administration 11.1 Understanding ServiceWise Integration Understanding System-Level Integration Understanding Events and Event Templates 11.2 Managing Incoming Mail Server Settings Enabling Autoretrieval in ServiceWise Projects Enabling Multiple Team Accounts Defining Team Accounts Defining POP3 Server Settings Defining MAPI Server Settings Defining the Reply-to Address of Outgoing Defining Reply To Addresses based on Employee Types 11.3 Managing Project Sending and Reply-to Addresses Enabling Team Reply-to Addresses Enabling Personal Addresses as Reply-to Addresses Enabling Personal Aliases as Reply-to Addresses Enabling Personalized Reply Name Page 5 of 145

6 Enabling Project Members to Choose Reply Addresses Defining Notification Send From Properties 11.4 Managing the Outgoing Mail Server 11.5 Managing Templates for Manual Messages Managing the Incident Template Managing the Resend Template Managing the Reply Template 11.6 Administering Incident Submission Settings Defining Employee Groups Enabling Field Mapping Customizing Field Mappings Tags Managing Incident Field Mapping Defining Field Mapping Understanding Incident Submission Formats Chapter 12 Event Administration 12 Chapter12 -- Event Administration 12.1 Understanding ServiceWise Events Events and incidents Understanding Event Administration Understanding Event Types Definable event types System event types 12.2 Defining General Event Settings Renaming Events in ServiceWise Projects Enabling the Calendar View 12.3 Managing System Event Templates 12.4 Managing Definable Event Templates Creating Event Templates Deleting Event Templates 12.5 Administering General Event Template Properties Defining Start Dates and Due Dates Defining the Event Template Scope Defining the Prefix and Help Notes Defining Event Number Restrictions Defining Event Template Identifiers 12.6 Administering Global Event Templates Defining Event Templates as Global Event Templates Defining Global Event Template Access Controls Displaying Global Events in Projects 12.7 Administering Event Submission Access Controls 12.8 Administering Event Editing Access Controls Administering Event Deletion Access Controls Enabling Employees to Delete Events 12.9 Administering Event Attachment Rules Managing Applicable Attachment Types Defining Form-Based Event State Automation Managing Regular Event Templates Creating Regular Event Templates Defining Closed Date Controls Defining Elapsed Time Controls Defining Event Template Scope Managing Asset Operation Event Type Event Templates Creating Asset Operation Event Templates Defining Asset Operations Defining Applicable Assets Defining Event Template Applicable Asset Rules Defining Price Schedules Managing Autodiscovery Asset Event Templates Understanding Asset Autodiscovery Event Asset Operations Creating Asset Autodiscovery Event Templates Managing Announcement Event Templates Enabling Automatic Event Status Definition Creating Sent Announcement Templates Managing Received Event Templates Creating Received Event Templates Chapter 13 Employee Administration 13 Chapter13 -- Employee Administration 13.1 Understanding Employee Management Understanding Employee Administration Employee view customization 13.2 Administering Employee View Customization Defining Employee View Terminology Defining Employee Dropdown List Size Limits Enabling Support for Login Aliases Customizing the Employee View Employee Page Customizing the Employee View Team Page Customizing the Employee View Incidents/Events Page Customizing Employee View Custom Pages 13.3 Administering Common Addresses 13.4 Managing Employee Types Creating Employee Types Defining Employee Type Access Controls Employee types and power users Understanding Employee Type Base Project Access Controls Page 6 of 145

7 Understanding Employee Type Work Project Access Controls Understanding Power Users Defining Employee Applicable Projects 13.5 Administering Employee Management Access Controls Defining Project Member Access Controls Defining Employee Page and Team Page Access Controls Chapter 14 Employee Web Portal Administration 14 Chapter14 -- Employee Web Portal Administration 14.1 Understanding the Employee Web Portal Understanding Employee Web Portal Administration Employee Web Portal access and security Employee Web Portal GUI customization Understanding Employee Web Portal and Project Types Understanding the EWP and the ServiceWise Employee View 14.2 Defining General Employee Web Portal Settings Enabling the Employee Web Portal Reloading Web Settings Defining Default Work Projects Defining the Title of the Employee Web Portal Defining Runtime Keys System runtime keys The system runtime key Base project runtime keys Work project runtime keys No runtime key Enabling Incident List Reports Displaying DevTrack Project Development Issues Customizing the Employee Web Portal Logos Displaying Multiple Projects to Employees 14.3 Managing Employee File Attachments Enabling File Attachments in the Employee Web Portal Defining Attachment File Size Limits Defining Forbidden File Types 14.4 Managing Registration Controls Enabling New Employee Self-Registration Enabling Inactive Employees to Log Into the Web Portal Defining New Employee Default Types Defining Registration Methods Defining Web Portal Registration Notifications 14.5 Managing Web Themes Understanding System-Defined Web Themes Importing Web Themes Exporting Web Themes Defining Default Web Themes Creating New Web Themes Editing Web Themes Deleting Web Themes 14.6 Managing Employee Web Portal Field Access Controls 14.7 Managing Page Style Customization Enabling the Employee Web Portal Home Page Managing Employee Web Portal Announcements Customizing the New Incident Page Page title New incident project selection header New incident HTML link title New incident submit help note New incident based on incident template Managing the Incident List Page Chapter 15 Administering Web Forms 15 Chapter15 -- Administering Web Forms 15.1 Administering FormWise Web Forms Enabling Web Activity Management (Web Clicks) Enabling FormWise for Standard Forms Enabling Employee Profile Questions Defining the FormWise URL Administering Web Points Defining Web Points Access Controls 15.2 Administering FormWise Autoreply Enabling Autoreply Defining Server Information 15.3 Understanding the FormWise Information Schema Web Clicks Manager Chapter 16 System-Level Web Administration 16 Chapter16 -- System-Level Web Administration 16.1 Managing System-Level ServiceWise Web Settings 16.2 Defining Web Publishing Access Options Defining Client Access 16.3 Administrating ServiceWise Web Support and System-Level Settings Defining the System Runtime Key Enabling Database Connection Pooling Defining the Number of Records in ServiceWise Web Defining ServiceWise Web Login Titles Defining Web Welcome Message 16.4 Managing ServiceWise Web System Settings Page 7 of 145

8 Defining the Web Server Path for Employees Defining the Web Server Path for Project Members Enabling Project Member Logins Using Domain Accounts 16.5 Managing Multiple Web Server Support 16.6 Managing Interproject Switching Chapter 17 Company Asset Administration 17 Chapter17 -- Company Asset Administration 17.1 Understanding Asset Inventory Administration Understanding the Asset Inventory Understanding Asset Definition and GUI Customization Understanding System-Level Asset Properties Understanding Category-Level Asset Properties Understanding Template-Level Properties 17.2 Managing Asset Template Subassets 17.3 Managing Asset Template Breakdowns 17.4 Customizing the Description Page Managing System Controls in the Description Page Managing Custom Controls in the Description Page Defining Usage And Quantity Tracking 17.5 Customizing the Value Page 17.6 Customizing the Support Plan Page 17.7 Managing Asset Custom Pages Adding and Removing Custom Pages Adding Custom Controls to Custom Pages Adding Asset Definition Custom Controls The Field Type attribute Field Level attribute 17.8 Managing Product Upgrade Rules in the Asset Inventory Defining Asset Upgrade Rules Editing Asset Upgrade Rules Chapter 18 Knowledge Administration 18 Chapter18 -- Knowledge Administration 18.1 Understanding ServiceWise Knowledge Management Understanding the ServiceWise Knowledge Base Understanding ServiceWise Client Knowledge Management Tasks Understanding Knowledge Items 18.2 Managing Knowledge View Access Controls 18.3 Managing Editing Tools Choosing an Editor Defining HTML Editor Folder 18.4 Managing Announcements Defining Blast Announcement Settings Defining Criteria for Redundant Announcements Enabling and Defining Announcement Engine Settings Defining Employee Subscription Options 18.5 Defining Dynamic FAQs Enabling and Defining Dynamic FAQ Server Settings 18.6 Customizing the Knowledge View Customizing the Description Page Customizing the History Page Customizing the Resolution Page 18.7 Managing ServiceWise-RightAnswers Integration 18.8 Backing up the Document Files 18.9 Managing ServiceWise Autorecommendations Expert keywords and expert keyword points Employee and team member keyword ranking points Keyword clicking points Defining Expert Keyword Points Defining Employee Ranking Rules Defining Project Member Ranking Rules Defining Search Engine Keyword Matching Points Chapter 19 Service Agreement Administration 19 Chapter19 -- Service Agreement Administration 19.1 Understanding ServiceWise Service Agreements Understanding ServiceWise SLA Management Understanding ServiceWise Service Agreement Configuration 19.2 Administering Service Agreement General Properties Enabling Service Agreement Support Defining Service Agreement Access Controls 19.3 Administering Support Schedules Adding Support Schedules Deleting Support Schedules Defining Support Schedule Support Times Managing Support Schedule Holidays 19.4 Administering Service Agreement Statuses Adding Service Agreement Statuses Activating or Deactivating Service Agreement Statuses Defining Service Agreement Status Messages Adding Service Agreement Statuses Activating or Deactivating Service Agreement Statuses Defining Service Agreement Status Messages 19.5 Administering Service Agreement Templates Creating Service Agreement Templates Page 8 of 145

9 Service agreement type Chapter 20 Professional Services Administration 20 Chapter20 -- Professional Services Administration 20.1 Understanding ServiceWise Professional Services Management Understanding Standard and Advanced Services 20.2 Enabling General Time and Service Management Features Enabling Professional Services Time Tracking Enabling Professional Services Cost Tracking Enabling Professional Services Sales Tracking Enabling Service Template Support Enabling Time Usage Recording Displaying the Billable Check Box to Employees 20.3 Administering Standard Professional Services Management Adding Work Types Editing Work Types Deleting Work Types Defining Account Type Hourly Rates Defining Project Member Hourly Rates Defining Project Member Hourly Rates Defining Standard Service Management Access Controls Understanding Standard Service Management Access Controls 20.4 Administering Advanced Time and Service Management Defining Project Work Order Reports Enabling Incident-level Cost Controls Enabling Incident-level Sales Budgets Enabling Event-level Cost Controls 20.5 Administering Service Templates Adding Service Templates Deleting Service Templates Editing Service Template Work Type Settings Defining Service Template Cost Calculation Methods Defining Service Template Sales Calculation Methods Defining Service Template Time Tracking Methods Managing Service Template Units and Unit Quantities Managing Service Template Sales Definitions Defining Maximum Support Services Per Incident or Event Defining Incident-based Service Templates Enabling and Defining Service Template Time Rounding Defining Service Template Access Controls Understanding Service Template Access Controls 20.6 Administering Service Template Work Codes Enabling Service Template Work Codes Defining Service Template Work Codes Defining Default Work Codes with Support Plans Defining Default Work Codes without Support Plan 20.7 Administering Service Template Volume Pricing Enabling Service Template Volume Pricing Chapter 21 Incident Notification & Escalation Administration 21 Chapter21-- Incident Notification & Escalation Administration 21.1 Administering Incident Notifications and Escalations Push and pull notification subscriptions 21.2 Administering the ServiceWise Mail Service Reloading Settings to ServiceWise Mail Service Defining Incident Notification Activity Dates 21.3 Administering Incident Notifications Enabling Incident Notification in a ServiceWise Project Defining Incident Notification Rules Administering Incident Notification Triggers System triggers 21.4 Administering Incident Escalations Escalation triggers Escalation conditions Escalation actions Subscribers Administering Incident Escalation Rules Understanding Incident Escalation Triggers Administering Incident Escalation Actions Escalation schedules Notification methods Incident reassignment actions Administering Incident Escalation Schedules Administering Incident Reassignment Actions 21.5 Administering Incident Notification and Escalation Conditions 21.6 Administering Incident Notification and Escalation Actions Notification methods Defining Notification Action Addresses Defining Notification Actions Defining Pager and Mobile Phone Notifications Defining Incident Notifications 21.7 Administering Potential Recipients and Subscriptions Identifying Potential Recipients of Notification Actions Potential recipient variables Defining the Scope of Potential Recipient Variables Defining User-Defined Address List Page 9 of 145

10 Chapter 22 Event Notification & Escalation Administration 22 Chapter22 -- Event Notification & Escalation Administration 22.1 Administering Event Notifications and Escalations Push and pull notification subscriptions 22.2 Administering Event Notifications Enabling Event Notification in a ServiceWise Project Defining Event Notification Rules Administering Event Notification Triggers 22.3 Administering Event Escalations Administering Event Escalation Rules Understanding Event Escalation Triggers Administering Event Escalation Actions Administering Event Escalation Schedules Administering Event Escalation Reassignment Actions 22.4 Administering Event Notification and Escalation Conditions 22.5 Administering Event Notification and Escalation Actions Identifying Notification Action Addresses Defining Event Notifications Chapter 23 Outlook Sync Administration 23 Chapter23-- Outlook Sync Administration 23.1 TechExcel Outlook Sync Overview 23.2 Feature Summary 23.3 Requirements 23.4 System Administration - Configuring TechExcel ServiceWise for use with Outlook Sync 23.5 User Configuration Configuring TechExcel Outlook Sync 23.6 Using TechExcel Outlook Sync Add an Outbound to ServiceWise Add a Sent or Received to ServiceWise Add an Outlook Task or Outlook Appointment to ServiceWise Understanding the ServiceWise Outlook Toolbar Synchronizing Events and Appointments Synchronize ServiceWise Events to Outlook Appointments/Tasks 23.7 APPENDIX: Installing TechExcel Outlook Sync Chapter 24 Smart Screen Administration 24 Chapter24 -- Smart Screen Administration Page 10 of 145

11 ServiceWise Admin Guide TechExcel ServiceWise Admin Guide Chapter 1 ServiceWise Concepts 1 Chapter 1-- ServiceWise Concepts This chapter provides a brief introduction to ServiceWise concepts and features. In this chapter: Understanding ServiceWise ServiceWise Administration Team Representation and Management Incident and Event Management Employee Management Knowledge Management and Communication Asset Management Professional Services Management ServiceWise Add-On Modules 1.1 Understanding ServiceWise TechExcel ServiceWise offers a complete solution for managinginternalhelp desk support the support services that are offered to a company s employees. Using TechExcel ServiceWise, support organizations may optimize every aspect of their support processes. Managing support incidents and events Managing employees Maintaining a knowledge base as a support resource Tracking company assets Managing professional services TechExcel ServiceWise provides a comprehensive, high-end solution that can be configured to match any internal support process ServiceWise Projects ServiceWise uses the project concept to represent and manage company employee and support management processes. In ServiceWise, each project represents a distinct area of work and is controlled by a set of administrator-defined workflow rules. There are two types of ServiceWise projects: base projects and work projects: A base project enables businesses to store and manage employee data. A work project enables businesses to manage specific activities related to internal help desk support. Every employee base project may support one or more work projects. Knowledge can also be shared among work projects. You can create a knowledge base so multiple support projects can all work together to build and share knowledge. Although all support incidents are work project-specific, project members may share incidents (interproject copying) and events (global events) across work projects. (as well as global events.) Base Projects Abase projectis a tool for storing and managing the employee, asset, and knowledge data that is shared by multiple work projects. The base project acts as a centralized datastore for the work projects and enables them to freely share employee, asset, and knowledge data while maintaining their own incident and event data, team structures, and workflow rules Subproject Management Subprojects organize the incidents tracked in a project into discreet subfolders to provide project teams with a clearer and more realistic view of the incidents managed in each project. Generally, subprojects represent incidents that are grouped together based on incident types, incident ownership, serviced employees, or schedules. But subprojects may be used to organize support incidents by any criteria that is useful or meaningful to the support organization. Every subproject is defined by s schedule start and end dates, access controls, and parent-child relationships with the other subprojects. Every subproject may be the parent of multiple subprojects, which in turn are the parent of child subprojects. 1.2 ServiceWise Administration ServiceWise administration is process of installing, integrating, and configuring a ServiceWise site an implementation of ServiceWise components, applications, and modules, and of customizing that implementation and its projects to support their internal business processes. TechExcel ServiceWise is designed to be extremely flexible so that businesses may quickly implement and define tools that enable them to run their business. TechExcel ServiceWise system administration and project customization tasks require no programming. All ServiceWise configuration, customization, and administrative tasks may be managed in the ServiceWise Admin client using point-and-click tools The ServiceWise model is designed so that businesses may configure ServiceWise projects to support business processes rather than changing their business to fit the limitations of the application. All projects, incidents, events, and employees are fully customizable so that support organization may track the data that is important to them. As we have seen, administrators may create as many or as few projects as are needed to manage and track their business and each project may be defined by unique incident, event, and workflow definitions. In addition, all access controls are defined on a project-by-project basis. ServiceWise users may log into and work in many different projects, be assigned a unique account type, privileges, and responsibilities in each project using a single ServiceWise license. ServiceWise administration is managed at two levels: the system level and the project level System-level Administration System-level administrative tasks include the creation of ServiceWise base and work projects, the creation and management of ServiceWise user accounts and licenses, and the administration of ServiceWise system configurations. System-level administrative tasks fall into three general groups: System-level project administrative tasks include the creation and maintenance of base projects and work projects as well as all ServiceWise site configurations. System-level user administrative tasks include the creation and management of user accounts and licensing, the definition of system team groups, and the creation and management of administrator account types. System-level tool administrative tasks include the installation of ServiceWise applications and modules, the configuration of the ServiceWise Server, ServiceWise Document Server, and TechExcel Search Engine, and all integration configurations. All system level administrative tasks are managed by a system administrator a licensed ServiceWise user that has been assigned a system administrator account type. A system administrator account type defines the privileges that are granted to that user in the ServiceWise site Project-level Administration System-level administrative tasks include the definition of what is tracked in the project, how it is tracked, and who may track that data. Project administration tasks may be broken into four inter-related areas: Project definition Page 11 of 145

12 Incident definition and GUI customization Project member administration Workflow administration Administrative Accounts and Access Controls Both system and project-level administration tasks are controlled by account type-based access controls. The access controls that enable administrators to perform system-level and project-level configuration and customization tasks may be defined independently of one another enabling support organizations to create many different administrative accounts with different levels of access and power. 1.3 Team Representation and Management ServiceWise enables project administrators to define and represent their support organizations based on their job responsibilities and team membership and to implement project workflow and security. All incident, employee, and knowledge management tasks in ServiceWise are controlled using a set of account type-basedaccess controls. The ability of project members to perform specific tasks may be controlled. The account type-based approach provides administrators with greater flexibility to customize project workflow and security to meet their unique requirements and procedures. Account types Team groups Group folders Account types TechExcel ServiceWise uses account types to coordinate project members in the project workflow and to implement security in ServiceWise projects. Anaccount typedefines the role of a user account the privileges and responsibilities granted to that user in a ServiceWise work project. Every licensed ServiceWise user is assigned an account type in each work project. The account type defines the role that the user plays in that project. Project members that have different responsibilities in different projects may be assigned account types that reflect their role in each project. In ServiceWise, all project-level access controls are assigned to account types and not to individual user accounts. Project members inherit privileges from the account type they are assigned in a project. A user may belong to many different projects and be assigned different account types in different work projects. Project administrators may define any number of account types in a project and assign a unique set of privileges to each account type providing them with the flexibility to define many different levels of project security Team groups A team group represents a group of project members that share a common set of responsibilities in a ServiceWise work project, but who do not necessarily share the same role or responsibilities. Whereas an account type represents a specific role, team groups represent a team of project members that belong to the same work group, but have different responsibilities. Using team groups, project administrators may organize project team members into smaller, more useful entities for the assignment of incidents, events, and employees. If the project administrator defines a team group as an applicable owner in an event template, every member of that team group is deemed to be an applicable owners of every event that is based on that event template Group folders The group folder concept reflects the fact that a support incident may belong to a group instead of an individual team member at a particular phase in its life cycle. ServiceWise group folders store common support incidents and enable flexible and definable workflow control. Group folders represent a kind of buffer between the a team group and the incidents assigned to that group. Each group folder is owned by a particular team and protected by access controls: View, Put, and Get privilege. Only those project members with the appropriate account type may view incidents assigned to a group folder (Get), add incidents to a group folder (Put), or forward those incidents to another project member or group. Group folders are particularly useful to administrators when they define project workflow and determine how tasks are distributed to project members in the project. Anything that may be assigned to a project member in the project may all be assigned to a group folder. 1.4 Incident and Event Management TechExcel ServiceWise delivers a flexible workflow model that enables project administrators to replicate and enforce their processes in ServiceWise projects. By combining administrator-defined incident workflow, incident routing, and incident escalation rules, TechExcel ServiceWise enables administrators to define flexible and powerful process management tools. Incident Management Event Management Incident Management The primary vehicle for managing and tracking support issues in ServiceWise are collections of data calledincidents. Eachincidentrepresents a particular task or set of tasks that must be managed by a support team. ServiceWise incidents are usually associated with an employee and one or more subtasks calledevents. Every incident is represented by a unique incident ID, a description of the incident, an incident workflow state, a work description, and other dynamic properties. Most incident properties are fully customizable. Project administrators may define which properties comprise an incident on a project-by-project basis. ServiceWise projects are fundamentally tools for creating, managing, and tracking incidents and related employees, events, and assets. Incident management tasks include: Tracking incidents Creating incidents Forwarding incidents Closing and reopening incidents The ServiceWise client GUI provides support teams with a central repository for viewing and updating all information about the incident. Project members can update incident details, add notes and note attachments, view incident history, or create links between related incidents. Meanwhile, at any time during its life cycle, project members may communicate with employees by web conversations, automated notifications, or personalized incident summaries by Incident Workflow Workflow rules enable project managers to define and track the flow of work between individuals and teams. Workflow is a business process used to manage the tasks that compose a project. A well-defined set of workflow rules enable an organization to perform tasks in an efficient and repeatable manner. Incident workflow rules enable project administrators to define rules for managing the incidents and events that are managed in each subproject and for determining which project members and employees are applicable to a subproject and its incidents and events. Project workflow determines the life cycle of ServiceWise incidents. Project administrators may define workflow settings once in TechExcel ServiceWise Admin, all project members will manage incidents according to existing processes. Incident routing enables administrators to define rules for automatically assigning incidents to appropriate project members based on the incident attributes and project member skills and workload. Incident escalation enables administrators to define rules for automatically escalating incident statuses if the due date has passed or if no progress has been made in several days. Project administrators may also enable notifications for all escalations Incident Escalations ServiceWise incident notification enables support teams to ensure that all appropriate stake holders are notified (by , pager, or mobile phone) whenever incidents are created, updated, or closed in a ServiceWise project. ServiceWise incident notification is based on administrator-defined incident notification rules. Incident notification rules consist of triggers, conditions, actions, and subscribers. ServiceWise enables administrators to manage bothpush andpull for each incident notification rule using subscription rules. Project administrators may mandate that Page 12 of 145

13 certain project members receive incident notifications for certain incidents while others mayopt inoropt outof individual subscriptions. Project administrators may also mandate that certain project memberneverreceive incident notifications based on incident notification rules Incident Routing Incident routing is an optional feature that enables administrators to define rules for automatically routing ServiceWise incidents to project members based on administratordefined routing rules. Incidents may be automatically routed and assigned to project members based on one of four sets of criteria: Based on project member workloads Based on project member skill levels Based on a formula that is based on the workload and the skill level of potential targets Based on availability administrators may optionally mandate that a user must be logged into a project to be subject to routing rules Incident Escalation ServiceWise incident escalation enables project teams to ensure that support incidents do not fall through the cracks by ensuring that project teams are automatically notified if insufficient progress is made on ServiceWise incidents during a defined time period. Escalation actions include reassigning the incident to a new owner, changing the progress state of the incident, or even automatically generating notifications. incident escalation Project teams may be notified by , pager, mobile phone, or personal folder based on an administrator-defined escalation schedule. If still no action is taken, incidents may be automatically reassigned to another project member, group, or group folder Events in views Project members may manage and track events in the Event view of the ServiceWise client. Events may also be managed in the Incident view, Employee view, and Calendar view. Most events are the child of a parent incident, are associated with a single employee, and owned by a single ServiceWise project member, and may be managed based on these relationships. The Event view displays events and information about incidents and employees that are related to specific events. Project members may also manage sibling events in the Event view. The Incident view displays incidents and information about all of the child events of each incident. The Employee view displays employees and information about all of the incidents and events associated with that employee Event Management TechExcel ServiceWise tracks day-to-day business activity as events. Events represent the to do items that project members must perform in the course of processing incidents. Every event is either an incident-specific event or a general event. As incidents progress through the incident life cycle, changing workflow states and owners, events may be attached to those incidents to support multi-tasking, track day-to-day activities, and enhance incident workflow. Typical events include calling or receiving a call from an employee, employee requests for equipment, an online meeting or visit to a site, receiving or sending , or approval from management. 1.5 Employee Management As an internal service and support solution, ServiceWise is designed to enable company support engineers ServiceWise project members to manage support requests from company employees, associates, and partners. TechExcel ServiceWise provides businesses with powerful internal service and support solutions that enable them to effectively manage and automate their service desk processes. Employee accounts represent the company employees for whom ServiceWise support engineers create, manage, and track incidents and events in a ServiceWise project. Employee accounts may be identified by their employee type, job function, site, division, department, and group. All employees may be tracked and managed by project members in the Employee view of the ServiceWise clients. TechExcel ServiceWise enables project administrators to define businesses objects, processes, and workflow rules that enable ServiceWise work project members to manage employees effectively. TechExcel enables businesses to manage employees through every step of the employee life cycle. TechExcel ServiceWise automates all employee-related processes and enables project members to view the complete history of employee interactions. TechExcel ServiceWise business and workflow rules ensure that employees are effectively managed and seamlessly transition between ServiceWise project members. TechExcel ServiceWise provides businesses with tools for analyzing employee needs and behavior. TechExcel web forms. TechExcel ServiceWise enables project members to effectively communicate and collaborate with employees by phone, , and web conversations. CTI, TechExcel ServiceWise enables project members to keep in constant contact with other project members and with employees by , web conversation, and the telephone through CTI. Project members may use tools to keep employees up-to-date on the status of their incidents and on individual events. Employee Web Portal Tracking Web Conversations CTI Integration Employee Web Portal The TechExcel Employee Web Portal is a secure, interactive Web site providing controlled access to a centralized communication hub and to support processes. The Employee Web Portal enables employees to submit and edit incidents through the Internet. The Employee Web Portal enables employees to view their incidents and events. The Employee Web Portal enables employees to access FAQs, upgrades and patch info, product documentation. The Employee Web Portal enables employees to search the knowledge base, download documents or software, and read whatever news or announcements administrators have determined they should see based on their role. The Employee Web Portal enables employees to conduct Web conversations with ServiceWise project members. The Employee Web Portal is composed of six views. Each Employee Web Portal view displays tools that enable employees to manage incidents, view reports, interact with ServiceWise personnel, or customize their personal information or preferences. Whenever problems do arise, employees may easily search the knowledge base for information that is specific to their particular incident saving time and reducing overall support costs. The Employee Web Portal enables employees to access helpful hints, upgrades, patch info or any other information an administrator believes is relevant based on their employee type or products purchased. The Employee Web Portal may be fully integrated with TechExcel DownloadPlus, enabling your users to download software or documents based on their profile Tracking Communication by between support engineers and employees is represented in ServiceWise project by events. Events represent the subtasks that must be performed before an incident can be resolved and closed. Events are generally the children of a parent incident and represent a task that must be performed within an incident workflow state. One of the most common events in ServiceWise projects to send or receive from an employee. All events are instances of an administrator-defined event template belonging to one of three event types: The Sent event type represents a set of business rules for managing sent to an employee from a ServiceWise project member. The Received event type represents a set of business rules for managing sent to a project member from an employee. The Announcement event type represents a set of business rules for managing announcement events Web Conversations The web conversation is a useful tool for communicating with employees. The Web Conversation page provides support project members a powerful tool for communicating with employees about their incidents. The Web Conversation page features a rich text chat-like interface, with time stamped and logged data input. Employees may communicate through the Employee Web Portal. Web conversations enable support team to see when employees add new web conversation to an incident. Incidents can be flagged in the Incident list so that the team members Page 13 of 145

14 can easily spot them. Flagged incidents may also be displayed in the home page of each team member. Team members may manually clear the web conversation flags by checking the Clear the New Employee Request check box on web conversation page and clicking the Submit button CTI Integration Computer telephony integration, or CTI, is a technology that enables telephone and computer interactions to be integrated or coordinated. TechExcel ServiceWise features CTI tools that enable support teams to improve employee support over the telephone by using a plug-and-play solution based on the CTI Data Connector (CDC) from Mirage Computer Systems. ServiceWise CTI integration introduces the following features: On-screen dialing of outgoing phone numbers from the TechExcel ServiceWise client improves support efficiency. Project members may dial employees by selecting phone numbers in the ServiceWise client. Automatic on-screen display of caller data for all inbound calls. PRoject members can immediately see who is calling and do not need to look up employee names and service history. On-screen caller ID of incoming and outgoing phone calls. ServiceWise CTI automatically matches incoming and outgoing calls with phone numbers stored in the base project. 1.6 Knowledge Management and Communication In ServiceWise, all company knowledge items documents, SOPs, web pages, FAQs, company announcements, blast messages, and attachments may be stored and managed in an integrated KnowledgeWise knowledge base. As with employee and asset data, the company knowledge base may be shared by multiple ServiceWise work projects. Every ServiceWise work project in a site has access to a common knowledge base through which they may share business intelligence. ServiceWise facilitates self-service by providing company employees access to the knowledge base through the Employee Web Portal. ServiceWise knowledge management tasks are carried out at two levels: the project level and the incident level. TechExcel KnowledgeWise Incident Knowledge Management Automatic Knowledge Suggestion TechExcel KnowledgeWise TechExcel KnowledgeWise is a key component in the TechExcel ServiceWise Suite of service management tools. KnowledgeWise provides businesses with a single knowledge base through which they can manage and share information across ServiceWise projects. The TechExcel KnowledgeWise distribution engine enables support organizations to enforce change management, security, and transparency to business knowledge and facilitates collaboration for distributed support organizations. KnowledgeWise features include: KnowledgeWise enables all stakeholders across multiple projects to access and view the most recent version of all documents. The ServiceWise Knowledge view enables support teams to manage all project-related knowledge items (documents, HTML links, topics and attachments) including internal design documents, system requirements, user specifications, and test cases in a central repository. KnowledgeWise organizes documents by functional area. All documents are linked to an activity and all stake holders involved in that activity may quickly view all relevant documentation. KnowledgeWise features built-in version control tools that ensure that all project support teams no matter where they are in world always have access to the most up-todate documents. KnowledgeWise provides support organizations with a secure repository for all for all project documentation. Access to all knowledge items is protected by privilege-based access controls. The ability of project members to view, edit, lock, check out, and check in protected files is based on their role in the planning project. Knowledge items include documents, HTML links, knowledge topics, and incident attachments. The knowledge base is protected by account type-based access controls. Support organizations may define different levels of access for both support engineers and for employees Incident Knowledge Management ServiceWise not only enables support organizations to manage and share company knowledge, it also facilities communication between support engineers in regards to specific incidents. As we have seen, a support incident is a tool that enables support engineers to manage and track a specific support task. As such, each support incident serves as a centralized repository for storing, managing, and sharing information. All incident-specific information is directly embedded in, or attached to, the support incident used to track the incident. incident-specific information may be managed and tracked in incident descriptions and work descriptions, incident histories, and incident notes and note attachments Automatic Knowledge Suggestion Employees may access company knowledge items through the Employee Web Portal. ServiceWise may automatically recommend knowledge items to customers and to project members. Knowledge items may be recommended to customers searching for knowledge items in the Employee Web Portal. ServiceWise may recommend knowledge items to ServiceWise employees based on three different factors: the expert points assigned to user-defined keywords (expert keywords) that are assigned to knowledge items, user-defined relevance rankings (customer ranking pointsandteam member ranking points), and system-generatedclicking points. ServiceWise weighs the relative weight of these three factors to determine which knowledge items are recommended to project members and employees based on the keywords they used for their knowledge search. Support organizations may configure ServiceWise Recommendation engine to determine the relative weight given to each factor. Knowledge items may be recommended to project members submitting incidents through . The relevance of knowledge items to knowledge searches is based on the keywords that the employee or project member defines for that search. Three factors determine the relevance of those keywords to knowledge items: Expert keywords and expert keyword points Customer and team member ranking points Clicking points 1.7 Asset Management TechExcel AssetWise enables organizations to manage their asset tracking, inventory management, service and repair, reservations and user assignment processes. An asset is represents any article or equipment that requires tracking. It could be a tangible asset, such as a mobile phone or a spare part for the mobile phone, or an intangible asset, such as licenses for software. Using AssetWise, support teams and employees may directly manage company assets and all asset-related items. Seamless integration with TechExcel ServiceWise enables support organizations to track all IT assets, inventory, usage, and locations. Profession service management tools include: TechExcel AssetWise Asset Inventory Management LANDesk and Microsoft SMS Integration TechExcel AssetWise Discovery TechExcel AssetWise AssetWise optimizes all aspects of project members asset-related processes, from detailed asset tracking by serial number, to purchasing, inventory tracking, service and repair, and product return management. It enables the employee support plan auto renewal to be possible by tracking and analyzing each support plan with a support status for every product project members employee has purchased. AssetWise is designed to be tightly integrated with TechExcel ServiceWise and TechExcel CustomerWise and to enable members of those projects to perform basic operations from within the ServiceWise Windows or Web client applications. AssetWise enables management to view and track all company assets so that they may better understand the IT environment, inventories, and IT spending. Track all company assets and related asset data including detailed location, inventory, and user information. Page 14 of 145

15 Manage asset inventories, locations, and costs. Associate incidents, problems, and change requests with particular assets. The service team may associate an incident or problem with assets providing better impact analysis information. Management may view asset locations and usage to aid in risk analysis of a proposed change. Optional asset discovery integration through AssetWise Discovery, LANDesk Management Suite, and Microsoft SMS enables businesses to automatically gather detailed asset data, monitor software usage, transfer files, and solve user problems Asset Inventory Management AssetWise asset structures called theasset Inventoryin TechExcel ServiceWise and theproduct Catalogin TechExcel CustomerWise facilitate the definition, management, and tracking of company assets. An asset is any article tangible or intangible that requires management and tracking. AssetWise asset structures enable support organizations to organize assets into distinctasset categories hardware, software, spare parts, licenses, keys, parking permits, office equipment, and so on based on shared properties. Asset management requires that support organizations track different kinds of data for different categories of assets. Hardware is managed and tracked differently than software. And software is tracked differently from licenses. Asset structure administration is serves a dual purpose: Asset structures define and organize company assets. Asset structures define the tools that project members use to manage assets in the AssetWise, ServiceWise, and CustomerWise clients. Asset structures determine how company assets are created, managed, and tracked in the AssetWise, ServiceWise, and CustomerWise clients LANDesk and Microsoft SMS Integration Asset detection applications enable IT organizations to reduce hardware and software costs and to make informed decisions about their need for hardware and software by providing them with visibility of all IT assets. TechExcel AssetWise features integration with Microsoft SMS or LANDesk through TechExcel AssetWise LinkPlus. AssetWise-SMS integration enables business to map assets with AssetWise asset templates, automatically synchronize autodetected assets, and to assign and manage ownership of assets by employees in TechExcel ServiceWise projects. TechExcel AssetWise IT auditing and inventory management solutions provide asset managers view to their entire network from personal computers and servers, to network printers and switches, to personally-owned gadgets like PDAs, USB sticks, and MP3 players TechExcel AssetWise Discovery TechExcel AssetWise enables support organizations to integrate their AssetWise asset management system with AssetWise Discovery, map autodetected assets to AssetWise asset templates, and to schedule the automatic synchronization of asset data. AssetWise-AssetWise Discovery integration provides support teams with greater control and flexibility to effectively manage their assets: Automatic transfer of autodetected assets in TechExcel AssetWise using an NT service. Support for integrated AssetWise Discovery asset operations within the TechExcel AssetWise client, ServiceWise Windows client, or CustomerWise client. Management and tracking of asset detection operations as events in TechExcel AssetWise, ServiceWise, and CustomerWise projects. Linking of autodetected IT assets to customer or employees and management of those assets in the TechExcel AssetWise, ServiceWise, and CustomerWise Windows clients. Enhanced asset management reports AssetWise Discovery makes critical IT audit metrics available to key stakeholders throughout the company. 1.8 Professional Services Management The TechExcel Service Agreement module is a comprehensive service level agreement solution that enables support organizations easily configure, sell, and administer service plans. ServiceWise service level agreements define the levels of service that are offered to company employees including the support schedule, and required response and resolutions times for each employee. ServiceWise service level agreements provide support organizations with a clear view of the service level expectations that are provided to company employees, help minimize misunderstandings, and enable support organizations to calculate and track the true costs of service provided. Profession service management tools include: Service Agreement Management Professional Services Management Service Agreement Management In ServiceWise, support organizations may define, manage, and track many different levels of support services that are available to company employees. Each employee support plan defines the guaranteed support schedules, response times, and resolution times that are offered to employees based on employee account types, incident types, and company assets. Moreover, service agreements define rules for automatically escalating incidents if the response time is exceeded. Using the ServiceWise Service Agreement Manager, support organizations may define service level targets and analyze service achievements and shortcomings. Service teams may continually improve the quality of their services and increase employee satisfaction using built in service level monitoring, escalation, and notification features. Analyze incident and problem records and service level accomplishments Identify unacceptable service levels and unreasonable service promises Improve employee understanding and satisfaction Define multiple service levels based on user defined variables Professional Services Management TechExcel ServiceWise offers professional service management features including time and cost tracking and budget monitoring and control. Support organizations may predefine prices based on the services offered (work types) or the employees served (employee type). When the service time is entered or calculated, the cost of the work is automatically calculated. 1.9 ServiceWise Add-On Modules TechExcel ServiceWise offers many add-on modules that enable support organizations to extend the power of their projects and provide them with the flexibility they need to integrate their ServiceWise projects with existing applications and processes. ServiceWise add-on modules include: TechExcel ServiceWise LinkPlus TechExcel FormWise ServiceWise Wireless TechExcel DownloadPlus TechExcel ServiceWise LinkPlus TechExcel ServiceWise LinkPlus provides support organizations with the means to integrate ServiceWise work projects with third-party or custom-defined business applications. Using ServiceWise LinkPlus, businesses may write and retrieve incident and event data to and from ServiceWise projects, synchronize data between ServiceWise and other business applications, and integrate ServiceWise projects with third-party business solutions. ServiceWise LinkPlus consists of a web service, a synchronization service, and a software development kit (SDK): TheServiceWise LinkPlus web serviceis a library of functions that enable businesses to integrate their ServiceWise support projects with third-party business applications to better manage employee, incident, and event data. Chapter 2 System-Level Administration 2 Chapter 2 -- System-Level Administration Page 15 of 145

16 This chapter provides a broad overview of system-level administration tasks and responsibilities and provides detailed instructions for creating and managing ServiceWise projects and sites. In this chapter: Understanding System-Level Administration Administering ServiceWise Projects at the System Level Managing Solution Templates Running the Go Live Wizard 2.1 Understanding System-Level Administration ServiceWise administration is managed at two levels: the system level and the project level. System-level administrative tasks include the creation of ServiceWise base and work projects, the creation and management of ServiceWise user accounts and licenses, and the administration of ServiceWise system configurations. System-level administrative tasks fall into three general groups:?system-level project administrative tasks include the creation and maintenance of base projects and work projects as well as all ServiceWise site configurations. System-level user administrative tasks include the creation and management of user accounts and licensing, the definition of system team groups, and the creation and management of administrator account types. System-level tool administrative tasks include the installation of ServiceWise applications and modules, the configuration of the ServiceWise Server, ServiceWise Document Server, and TechExcel Search Engine, and all integration configurations. All system level administrative tasks are managed by a system administrator a licensed ServiceWise user that has been assigned a system administrator account type. A system administrator account type defines the privileges that are granted to that user in the ServiceWise site. Once a user account is designated as a system administrator, that user may log into ServiceWise Admin using their username and password and configure system-level settings. All system-level administrative tasks are performed in the System Settings project. 2.2 Administering ServiceWise Projects at the System Level In ServiceWise, aprojectis a tool for storing, organizing, and managing incident, event, employee, asset, knowledge, and project team data. Every ServiceWise implementation called aservicewise site consists of two different types of projects: base projects and work projects. Abase projectis a tool for storing and managing the employee, asset, and knowledge data that is shared by multiple work projects. Awork projectis a tool for storing and managing incident and event data. Every work project represents adistinct area of workand is defined by unique team structures (account types, team groups, and group folders) and workflow rules. Every ServiceWise work project is linked to a single ServiceWise base project. Generally, the configuration and customization of ServiceWise projects is the responsibility of a project administrator. However, many project administrative tasks are the responsibility of the system administrator. ServiceWise system-level project management tasks include: Understanding Active and Inactive Projects Creating ServiceWise Base Projects Creating New Work Projects Copying ServiceWise Project Settings Backing Up ServiceWise Projects Restoring Backed Up Projects Creating Projects Based from Backed Up Projects Deleting ServiceWise Projects System administrators may create, delete, open, close, back up, and restore ServiceWise base projects and work projects in the General System Settings folder of the ServiceWise Admin client Creating ServiceWise Base Projects Abase projectis a tool for storing and managing the employee, asset, and knowledge data that is shared by multiple work projects. The base project acts as a centralized datastore for the work projects and enables them to freely share employee, asset, and knowledge data while maintaining their own incident and event data, team structures, and workflow rules. System administrators may create new ServiceWise base projects using the New Project command in the File Menu. The New Base Project dialog box enables administrators to define the project title, the project type, and to import project settings from previously-defined projects. When creating a ServiceWise base project, system administrators may create the project from scratch or they may import project properties from previously defined ServiceWise projects. For information on importing project properties from other ServiceWise projects see Copying ServiceWise Project Settings on page 25. To create a new ServiceWise base project: 1Invoke the New Project command. The New Project command is accessible by three methods: Click the New Project button in the tool bar. Select the New Project command in the File menu. Press CTRL + N. The New Project dialog box appears. 2Select the Base Project option and click the OK button. If a base project already exists, a warning message appears. Click the Yes button. The New Base Project dialog box appears. 3Enter a project title in the Project Name field. Avoid using the following characters when naming a base project: / \ :? < >. 4Select the internal ServiceWise project type option. Currently, only the internal ServiceWise project type is supported in TechExcel ServiceWise. 5Click the OK button Creating New Work Projects Awork projectis a tool for storing and managing incident and event data. Every work project represents adistinct area of workand is defined by unique team structures (account types, team groups, and group folders) and workflow rules. Every ServiceWise work project is linked to a single ServiceWise base project. System administrators may create new ServiceWise work projects using the New Project command in the File menu. The New Work Project dialog box enables administrators to define the project title, the base project and to import project settings from previously-defined projects. To create a new ServiceWise work project: 1Invoke the New Project command. The New Project command is accessible by three methods: Click the New Project button in the tool bar. Select the New Project command in the File menu. Press CTRL + N. The New Project dialog box appears. Page 16 of 145

17 2Select the Work Project option and click the OK button. The New Work Project dialog box appears. 3Enter a project title in the Project Name field. Avoid using the following characters when naming a work project:/ \ :? < >. 4Select the internal ServiceWise project type option. Currently, only the internal ServiceWise project type is supported in TechExcel ServiceWise. 5Click the OK button Copying ServiceWise Project Settings System administrators may use the New Project dialog box to create new ServiceWise projects based on previously-defined ServiceWise projects. System administrators may import settings when creating new base projects or work projects. The Copy Settings from an Existing Project command enables administrators to import project properties into the new project. Copying ServiceWise project settings cuts down the time required to configure a ServiceWise project if the different projects share similar information. The project settings that the administrator may import into the new project depend on the project type. For work projects administrators may import any of the following settings: Project members, groups, and group folders Workflow settings Timetrack settings Search Queries and Queries Auto Routing settings Knowledge view settings integration settings Incident Notification settings Auto Escalation settings Auto Assign settings Service Agreement settings Event Management settings For base projects administrators may import any of the following settings: Project members, groups, and group folders Workflow settings Timetrack settings Search Queries and Queries Auto Routing settings Knowledge View settings integration settings Incident Notification settings Auto Escalation settings Auto Assign settings Service Agreement settings Event management settingsmay notbe imported for base projects. To create ServiceWise projects based on existing projects: 1Select the New Project command in the File menu. The New Project dialog box appears. 2Select the Base Project or Work Project option and click the OK button. The New Project dialog box appears. 3Define project settings. Project name Project type Base project (for work projects only) 4Select the Copy Settings from an Existing Project check box and click the OK button. A list of all existing projects is displayed in the Project list. 5Select a project in the Project list. 6Click the OK button. The Copy Project Settings dialog box appears. 7Select the project settings options to be imported and click the OK button. The new project opens Understanding Active and Inactive Projects Every ServiceWise project has either an active or inactive status. The status of a project determines the tasks that an administrator may perform on that project. System administrators define the status of a project by selecting the Active Project check box in the Project Properties page of the General Project Settings folder of the ServiceWise Admin client. All project status settings are defined on a project-by-project basis in the appropriate project view Active projects System administrators may perform the following tasks in active ServiceWise projects: System administrators may open active projects in ServiceWise Admin and configure project settings. System administrators may use the Support Member Manager to add user accounts as project members to active projects. System administrators may import project properties from active projects Inactive projects Inactive ServiceWise projects may be deleted using the Delete Project command in the File menu. Active projects cannot be deleted Backing Up ServiceWise Projects System administrators may use the Backup Project command and the Back Up Project dialog box to back up individual ServiceWise projects or the entire ServiceWise database. ServiceWise stores backups of ServiceWise projects in a proprietary SWS file format. Once the administrator define the project information, the administrator may back up either the entire database or only selected projects. ServiceWise Admin creates the backup file with the selected project data. ServiceWise Admin stores backed up projects in a proprietary SWS file format. To back up ServiceWise projects: 1Invoke the Back Up Project command. Select the Back Up Project command in the File menu. Press CTRL + B. The Back Up Project dialog box appears. 2Click the Ellipsis button to navigate to the location of the backup file. The Backup dialog box opens. 3Navigate to the location of the backup files. 4Enter a name for the SWS file in the File Name field. Page 17 of 145

18 5Select the ServiceWise Backup File SWS option in the Save as Type dropdown list. 6Click the Save button. The Backup dialog box closes. 7Select a back up option: Click the Settings Only option to back up project settings. Click the Settings and Data option to back up project settings and project data. 8Select an option in the Projects Selected area: To back up all projects, select the All Projects radio button. To back up selected projects, select the Selected Projects radio button and click the applicable projects in the Project Name to Select/Deselect list. 9Click the OK button. The project is backed up Restoring Backed Up Projects System administrators may use the Restore Project command to restore backed up projects and backed up databases. When restoring backed up ServiceWise projects administrators may overwrite existing projects or create new projects based on the backed up projects. Note:Restoring a project may take several minutes to a few hours, depending on size of the project. ServiceWise stores backups of ServiceWise projects and databases in a proprietary SWS file format. System administrators may back up selected projects or the entire database using the Back Up command in the File menu. The Restore Project command enables administrators to restore projects or databases from SWS files. The Restore Manager enables administrators to choose which projects are restored from a SWS file, what is restored (data, settings, or data and settings), and the method used to restore projects. Figure 2-1: Restore Manager The options available to administrators in the Restore manager depend on whether they are attempting to restore individual projects or an entire database. System administrators may choose one of three restoration options: The Both Settings and Data option The Settings Only option The Data Only option The restoration option selected is applied to all projects backed up in the SWS file. Note:Restoring project data may delete the existing data in the current database. The Restore data operation should only be used to recover a damaged database or to move project data to another server computer. System administrators may select a different restoration method for each project to be restored. Skip, do not restore this project Restore to the same project, overwrite records Restore project, do not overwrite records Alternatively, administrators may create new projects based on a backed up project. To restore ServiceWise projects: 1Invoke the Restore command. Select the Restore command in the File menu. Press CTRL + R. 2Locate the backed up project and click the Open button. ServiceWise stores backups of ServiceWise projects in a proprietary SWS file format. The Restore Project manager appears. 3Select an option in the Restore Options area. System administrators may choose one of three restoration options: Both Settings and Data Settings Only Data Only 4To restore system settings, select the Restore System Settings check box. 5Select a project in the Projects to Restore list. 6Select an option in the Restore Method area. System administrators may select a different restoration method for each project. Skip, do not restore this project Restore to the same project, overwrite records Restore project, do not overwrite records 7Apply the restore method to one or more projects: To apply the restore method to a single project, select the Apply button. The restore method for the selected project in the Projects to Restore list is updated. To apply the restore method to projects displayed in the Projects to Restore list, select the Apply All button. 8Click the OK button. The project is restored Creating Projects Based from Backed Up Projects System administrators may use the Restore command to create new ServiceWise projects from backed up copies of existing projects. TechExcel ServiceWise automatically assigns the project a new project ID number. Whenever an administrator backs up a ServiceWise project, ServiceWise saves a copy of that project in a proprietary SWS file format. System administrators may create a new ServiceWise project from SWS files. To create a new project from a backed up project: 1Invoke the Restore command. Select the Restore command in the File menu. Press CTRL + R. 2Locate the backed up project and click the Open button. ServiceWise stores backups of ServiceWise projects in a proprietary SWS file format. The Restore Project manager appears. 3Select an option in the Restore Options area. Page 18 of 145

19 System administrators may choose one of three restoration options: Both Settings and Data Settings Only Data Only 4To restore system settings, select the Restore System Settings check box. 5Select a project in the Projects to Restore list. 6Select the Restore to a New Project option in the Restore Method area. 7Define the name of the new project in the New Project Name text field. 8Apply the restore method to one or more projects: To apply the restore method to a single project, select the Apply button. The restore method for the selected project in the Projects to Restore list is updated. To apply the restore method to projects displayed in the Projects to Restore list, select the Apply All button. 9Click the OK button. The new project is created Deleting ServiceWise Projects System administrators may use the Delete command to deleteinactiveservicewise projects. System administrators may only delete projects that have an inactive status. For instructions on making a project inactive see Understanding Active and Inactive Projects on page 26. To delete a project: 1Select the Delete command from the File menu. The Delete Project dialog box appears. The Delete Project dialog box displays all of the projects that may be deleted. Only those projects that have an inactive status may be deleted. 2Select a project. Click the Delete button. 2.3 Managing Solution Templates TechExcel ServiceWise features solution templates preconfigured, powerful out-of-the-box business solutions that enable administrators to speed the deployment of ServiceWise systems and to enable businesses to optimize their business processes using TechExcel ServiceWise. Solution templatesare tailored to support a variety of business needs. By selecting the solution template that most closely matches the needs of a business, administrators may quickly evaluate TechExcel solutions and recognize their power to optimize business processes. Thesolution template documentdescribes the business processes included in solution template. System administrators may use the configuration document as the blueprint for defining business processes and provides a documented view of ServiceWise solutions. TechExcel has taken its deployment and configuration experience and, with best practices in mind, has configured each solution template to ease the deployment and use of our solutions. The combination of ready-to-use business solutions and the ability to customize and refine those solutions helps to keep evaluation and deployment costs down and minimizes time-to-deployment while maximizing the return on investment and business efficiency. Solution template management tasks include: Installing Solution Templates Viewing Solution Template Notes Updating the Solution Template Configuration Document Installing Solution Templates Each solution template includes both a configuration file and a solution template configuration document. Loading the configuration file loads the pre-configuration that most closely matches the business needs of different industries. The installation process places a heavy load on the database, which may in turn significantly slow down the application. TechExcel recommend that administrators log off all the users while installing solution templates. To install solution templates: 1Select the Install Solution Template command in the File menu. The Install Solution Template File wizard appears. Once selected, TechExcel ServiceWise will automatically load the selected solutions project data in that file. 2Locate the solution template on the local machine or network. Solution Template configuration files are stored in a proprietary SLT format. 3Click the Next button. 4The File Information page appears. The File Information page describes the solution template to be installed. 5Click the Next button. The Confirmation page appears. The Confirmation page enables administrators to run a full analysis to compare the contents of this solution template with the data in the current system. 6Compare current data with that contained in the solution template. To run the comparision, click the Next button. To skip the comparision, select the Skip Comparision check box and click the Next button. The Analyzing page appears. 7Click the Start button Viewing Solution Template Notes Solution templates can be very beneficial to both the evaluation and deployment of TechExcel ServiceWise. System administrators may learn more about solution templates and determine which template makes sense for their company in the solution template notes. To view the solution template notes, select the Show Solution Template Notes command in the File menu Updating the Solution Template Configuration Document Thesolution template configuration documentdescribes the business processes included in the configuration file. System administrators may use the configuration document as the blueprint for defining business processes and provides a documented view of ServiceWise solutions. Updating solution template configuration document to include all significant changes made to the system ensures that the business process document is always be up to date. 2.4 Running the Go Live Wizard The Go Live Wizard enables organizations using test data or soltution templates to configure their ServiceWise site and projects in a test environment to remove the data prior to going live in a production environment. The Go Live Wizard removes all extraneous team members, customers, and other sample data. Administratirs must not run the Go Live Wizard wizard ifanyproduction data is in any project within the current ServiceWise database. The Go Live Wizard may delete this data. The Go Live Wizard may be used in conjunction with TechExcel solution templates. System administrators may load solution templates and customize their ServiceWise system to suit their business needs using solution template sample data. After making customizations to the solution template, administrators may run the Go Live Wizard to clean up data entered in the test environment. To run the go live wizard: 1Select the Go Live Wizard command in the File menu. System administrators may run the Go Live Wizard in either base projects or work projects. Page 19 of 145

20 2The Go Live Wizard Introduction page is displayed. 3Enter the password in the Password to Go Live text field. A password is required to run the Go Live Wizard. System administrators must contact TechExcel to get the Go Live Wizard password. 4Click the Next button. The Go Live Wizard second page appears. 5Enter a brief note. This note will be logged to the database and must be at least twenty characters long. The note ensures that the administrator is purposely executing the Go Live Wizard and not simply clicking through the wizard to test the feature. Once the note has the required characters, click the Next button. 6Select the data that is to be removed from the database. The following data may be removed using the Go Live wizard: Delete all data related to events, sales, incidents, assets, and customers (will gray out all other options) Delete all customers and related incidents (will gray out the remaining two options) Delete all incidents and events Delete all assets 7Click the Next button. A dialog box appears. 8Confirm the deletion of the data. 9Delete the sample or test team members that are not be a part of the production project. Selecteach user to be deleted and click the Delete button. Replace each deleted user with an applicable team member. 10Click the Next button. The Go Live Wizard last page appears. 11Click the Finish button. Chapter 3 System-Level User Administration 3 Chapter 3 -- System-Level User Administration This chapter covers the system-level administration user tools in TechExcel ServiceWise Admin including the Support Member Manager, the License Manager, and the Login Manager. System-level user administration activities include the creation and management of user accounts, configuration and management of LDAP integration, and the management and distribution of TechExcel ServiceWise user licenses. In this chapter: Administering User Accounts at the System Level Defining Team Member Contact Information Importing and Exporting User Accounts Administering System Team Groups Administering User Logins Administering User Licensing Managing Administrator Account Types and Access Controls 3.1 Administering User Accounts at the System Level In TechExcel ServiceWise user administrative responsibilities are split between the system administrator (who administrates the entire ServiceWise implementation) and individual project administrators (who administrate projects within the implementation). System administrators are responsible for creating user accounts, defining user account properties, and assigning licenses to ServiceWise users. Project administrators may add system administrator-defined user accounts to their projects and assign account types to these user accounts. System administrators may use controls in the Support Member Manager to create, edit, delete, and merge user accounts. User accounts are shared across all projects in a TechExcel ServiceWise implementation. Each user account consists of a set of user attributes that define basic information about a user such as that person s first and last names, phone numbers, and addresses. Each user account is identified by a unique user name and password which enable the user to work in the ServiceWise application. Project administrators may add user accounts to a project after they have created account types and assigned project-level privileges to those account types. A user account may not be added to a project unless that user account is assigned an account type. User account management tasks include: Understanding the Support Member Manager Creating and Editing User Accounts Defining General User Data Defining User Administrative Access Controls Defining User Administrative Access Controls Defining Team Member Contact Information Deleting User Accounts Defining User Profiles Importing and Exporting User Accounts ing the ServiceWise Installer to Project Members Understanding the Support Member Manager System administrators may use the Support Member Manager to create, edit, delete, and manage user accounts. The Support Member Manager displays high-level information for every project member in a ServiceWise implementation and controls that enable system administrators to manage user accounts: Page 20 of 145

21 Figure 3-1: Support Member Manager Colored icons clearly identify ServiceWise users: System administrators are displayed with a red icon. Project administrators are displayed with a turquoise icon. Active single-product license or suite license users are displayed with a green user icon. Active light support license users are displayed with a yellow icon. Inactive users are displayed with a gray icon Support Member Manager controls The Support Member Manager displays seven different controls that enable system administrators to manage project members. The User Selection dropdown list enables administrators to filter the project members displayed in the Support Member Manager list by their user status: all users, active users, or inactive users. The Invite Selected Users to Install Client button enables administrator to a link to the ServiceWise client installation program to the selected project member. The New button enables administrators to create new project members in the project. The Edit button enables administrators to edit project members in the project. The Delete button enables administrators to delete project members from a project. The Merge button enables administrators to merge into a single project member multiple user accounts. The Import button enables administrators to import user account data. The Report button enables administrators to view the User Information report Creating and Editing User Accounts System administrators may use the New button the Support Member Manager to create new ServiceWise user accounts. Once a system administrator has created a user account and defined the user properties for that account, project administrators may add that user account to ServiceWise work projects. The Member Information page enables system administrators to define the user account properties for new and existing ServiceWise user accounts. Figure 3-2: The User Information Manager The Member Information page consists of three tabs: the General tab, the License/ Privilege tab, and the Advanced tab. The General tab displays basic user account properties including their name, , and user status in the ServiceWise implementation. The Advanced tab displays controls that enable the administrator to define a user s pager and mobile phone numbers and addresses. To create a user account: 1Click the Support Member Manager icon in the tool bar. The Support Member Manager appears. 2Click the New button. The Member Information manager appears. The Member Information manager displays three tabbed pages: the General tab, the License/Privilege tab, and the Advanced Settings tab. 3Define basic user account properties in the General tab. For detailed instructions see Defining General User Data. 4Define licensing and system administrative privileges in the License/Privilege tab. For detailed instructions see Defining User Administrative Access Controls and Managing User Licenses. 5Define contact information in the Advanced Settings tab. Page 21 of 145

22 For detailed instructions see Defining Team Member Contact Information. 6Click the OK button. The user account is displayed in the Support Member Manager list. To edit a user account: 1Click the Support Member Manager icon in the tool bar. The Support Member Manager appears. 2Select the user account in the Support Member Manager list. 3Click the Edit button. The Member Information page appears. 4Define basic user account properties in the General tab. For detailed instructions see Defining General User Data. 5Assign the user account to a system team group in the General tab. A system team group is an administrator-defined grouping of users that represents a internal company structure such as a product division or an office. For more information see CreatingSystem Team Groups. 6Define licensing and system administrative privileges in the License/Privilege tab. For detailed instructions see Defining User Administrative Access Controls and Managing User Licenses. 7Define contact information in the Advanced Settings tab. 8Click the OK button Defining General User Data System administrators may define basic account properties including user names, passwords, and phone numbers whenever they create or edit ServiceWise user accounts. The General tab displays basic user account properties including their name, , and user status in the ServiceWise implementation. The basic user account properties displayed in the Basic tab include: Member Name:The Member Name property represents the name that the project member uses to log into the application. First Name:The First Name property stores the first name of project members. Last Name:The Last Name property stores the last name of project members. Initial:The Initial property stores the first initial of the project member s middle name. Password:The Password property stores the password that project members use to log into the ServiceWise project. Confirm Password:The Confirm Password control enables administrators to confirm the password entered in the Password control. Phone (W):The Phone (W) property may be used to store the work phone number of project members. Phone (H):The Phone (H) property may be used to store the work phone number of project members. Fax:The Fax property may be used to store the fax number of project members. The property may be used to store the address of project members Defining User Administrative Access Controls System administrators may use controls in the Support Member Manager to define a grant administrative privileges to users within a ServiceWise implementation. TheIs a System Administrator optionenables the user to perform system administrative tasks. A system administrator has TechExcel ServiceWise Admin access to all system level features and full access to all projects in TechExcel ServiceWise. TheIs a Project Administrator optionenables the user to perform system administrative tasks. A project administrator has TechExcel ServiceWise Admin access to only those projects for which they have been defined as project administrator. TheIs an Asset Administrator optionenables the user to administrate asset management setting in AssetWise. An asset administrator has access to AssetWise Administrator, a separate application available if the AssetWise add-on module is purchased. TheIs an Form Administrator optionenables the user to manage forms in FormWise A form administrator has access to create and manage forms in FormWise, a set of features available in the TechExcel ServiceWise client Deleting User Accounts System administrators may use the Delete button in the Support Member Manager to delete user accounts from ServiceWise projects. System administrators may only delete user accounts that are not members of any ServiceWise project. For step-by-step instructions on removing a user account from a project see Defining User Profiles on page 40. To delete a user account: 1Select an inactive user account in the Support Member Manager list of the SupportMember manager. System administrators may only delete inactive user accounts. 2Click the Delete button. The warning dialog box appears. 3Click the OK button Defining User Profiles System administrators may use the User Profile page in the Support Member Manager to define a user profile for an account type within a ServiceWise project. The User Profile page of the Support Member Manager enables the administrator to assign an account type, team group membership, and workflow rules for a user account in one place. The User Profile page consists of three tabs. Each tab in the User Profile page enables the administrator to define a different aspect of the user profile for a user account. To assign an account type: 1Select the user account in the Support Member Manager list. 2Click the Profile button. The User Profile page appears. 3Select the Account Type tab. 4Select a project in the Project list. 5 Optional:To make the user account a project member select the Is a Project Member check box. 6 Optional:To assign an account type select an option from the Account Type dropdown list. To define team group membership: 1Select the user account in the Support Member Manager list. 2Click the Profile button. The User Profile page appears. 3Select the Group Member tab. 4Select one or more project members in the Group list. The project member is added to a project members if a black check mark appears in the check box next to the project members name. To define workflow ownership rules: 1Select the user account in the Support Member Manager list. 2Click the Profile button The User Profile page appears. 3Select the Workflow tab. 4Select workflow states in the Workflow State list. The project member may be an applicable owner of an incident in each workflow state if a black check mark appears in the check box next to the name of the workflow state. Page 22 of 145

23 ing the ServiceWise Installer to Project Members System administrators may use the the Selected Users for Client Installation button to a link to the ServiceWise client installation program. Once the administrator has defined all user accounts and defined project membership, the administrator may use this command to send the ServiceWise installation program available to future ServiceWise project members. To the client installation program: 1Click the Support Member Manager icon in the tool bar. The Support Member Manager window appears. 2Select a user account in the Support Member Manager list. 3Click the the Selected Users for Client Installation button Managing User Licenses System administrators may define a user licensing settings whenever they create or edit a user account in the Support Member Manager. System administrators may assign different types of licenses user account. The License/Privilege tab displays controls that enable administrators to assign licenses to user accounts. Figure 3-4: Advanced Tab in the Member Information Page System administrators may assign one of two different classes of licenses to each ServiceWise user account. Alternatively, administrators may choose not to assign a license to a user account. The No License (Inactive User) option defines the user account as inactive. Inactive users cannot log into ServiceWise projects. The Fixed License option assigns a fixed license to a user account. A fixed license enables a project member to log into any project in a site family. The Floating License option enables a user account to use a floating license to access projects in a ServiceWise site. Floating licenses are not assigned to any one user, but are assigned to a particular ServiceWise site. Floating licenses regulate the number of users who may be logged into a ServiceWise site at one time. A single floating license may be assigned to three different users, but only one of those users may log into ServiceWise at any one time. System administrators may also assign a license type to each ServiceWise user account. The Support License option enables project members to perform all activities in a project granted to them by the project administrator based on their account type. The Light License option restrict the ability of project members to perform certain actions in ServiceWise projects. Light licenses enable users to log into ServiceWise projects through the Employee Web Portal. For more information on privileges available users holding a light license see Understanding Light License Access Controls. 3.2 Defining Team Member Contact Information System administrators may define pager and mobile phone contact settings for ServiceWise users whenever they create or edit a user account in the Support Member manager. Contact information defined in the Advanced tab of the Support Member manager Team member contact management tasks include: Defining User Autologin Settings Defining User Pager Service Information Defining User Mobile Service Information Defining User Account Signatures Defining User Autologin Settings The Auto Login Name represents the domain user name used for TechExcel ServiceWise Web if NT authentication is enabled. System administrators may define the login name here, or allow the Web server to automatically populate the login name. TechExcel ServiceWise Web automatically links the NT domain user account with the User ID if this feature is enabled Defining User Pager Service Information System administrators may define user pager service information in the Advanced tab of the Support Member Manager. Controls in the Pager Service area of the Advanced tab enable administrators to manage user pager information including their provider, type, and address.the secondary address may also be specified for paging purposes. A drop down menu enables the administrator to specify if the pager is numeric or alpha numeric (text). This information can be used for notifications Defining User Mobile Service Information System administrators may define user mobile phone information in the Advanced tab of the Support Member Manager. This information can be used for notifications Defining User Account Signatures An signature is a brief message that is automatically added to the bottom of messages sent from a ServiceWise project. Signatures frequently display the name, job title, phone number, and other contact information of the sender. Signatures may also be used to add boilerplate paragraphs to all outgoing messages. Administrator-defined user account signatures are unique signatures that are appended to all sent from a particular user account in a ServiceWise site. In ServiceWise, signatures may be defined at two other levels besides the user account level. Manual template signatures are signatures that are appended to messages manually sent by project members from within the ServiceWise client. System administrators may define three different templates: the Incident template, the Resend template, and the Reply template. Each template may have a unique signature. Notification template signatures are signatures that are appended to messages that are automatically sent from a ServiceWise project based on administrator-defined notification rules. The signature displayed in an outgoing depends on administrator-defined notification configurations. To enable and define ServiceWise user account signatures: 1Select the Team Member Address Assigned to the Team Member option in the Default Reply Address dropdown list of the General Settings tab of the Integration page. The administrator-defined signature overwrites both manual template signatures and notification templates only if this option is selected. If this Page 23 of 145

24 template. Each template may have a unique signature. Notification template signatures are signatures that are appended to messages that are automatically sent from a ServiceWise project based on administrator-defined notification rules. The signature displayed in an outgoing depends on administrator-defined notification configurations. To enable and define ServiceWise user account signatures: 1Select the Team Member Address Assigned to the Team Member option in the Default Reply Address dropdown list of the General Settings tab of the Integration page. The administrator-defined signature overwrites both manual template signatures and notification templates only if this option is selected. If this option is not selected, the administrator-defined user account signatures are ignored. 2Double-click a user account in the Support Member manager. The Member Information manager appears. 3Enter the text of the signature in the Signature control of the Advanced tab in the Member Information manager. 4Click the OK button. 3.3 Importing and Exporting User Accounts System administrators may import user account attributes from a structured text file or an LDAP directory into the base project of a ServiceWise site Importing User Accounts from Structured Text Files Structured text breaks data into distinct rows and columns using field delimiters and text qualifiers. The field delimiter defines the beginning and end of each field imported. System administrators may between five different delimiters: The pipe character ( ) usually gets the best results. Text qualifiers define the beginning and end of text within fields and indicate that the Import Wizard should interpret the text exactly as it appears in the structured text file. Text qualifiers should be used if the text contains spaces or characters that might be read as field delimiters. Any character may be used as a text qualifier, but the default text qualifier is the double quotation mark ( ). The Import wizard enables system administrators to quickly create multiple user accounts. To import user account attributes: 1Click the Support Member Manager icon in the tool bar. The Support Member Manager window appears. 2Click the Import button. The Select a User Import Source dialog box appears. 3Select the Import from an External File option. The File and Format dialog box appears. 4Inthe User Information field locate the file that contains the data that may be imported. 5Select a field delimiter from the Field Delimiter dropdown list. The fields delimiter defines the beginning and end of each field that an administrator may import. System administrators may choose from five different delimiters:#, ; {tab} 6Enter a text delimiter in the Text Delimiter field. 7 Optional:To exclude Field names from the first row, select the Field names on the first row check box. 8Select the Next button. The Mapping User Fields dialog box appears. 9For each field displayed in the User Field column select an option from the appropriate Column in File dropdown list. 10Click the Next button. The Import page appears. 11Select all appropriate options in the Import dialog box. To overwrite duplicate records, select the Overwrite check box. To keep a record of all records in the text file that are not loaded into the database check the Log failed or skipped records check box. System administrators may define where ServiceWise saves the test file by selecting the Browse button. 12Click the Finish button Importing User Accounts from a LDAP Server ServiceWise-LDAP integration enables administrators to manage user data (user names, phone numbers, and so on) in a directory server instead of their ServiceWise sites. System administrators may import user account attributes from an integrated LDAP server intoa ServiceWise base project using the LDAP Import wizard. Table 3-1: Select Support Members Wizard The LDAP Import wizard enables administrators to quickly create or update project user accounts by importing data from an integrated LDAP server. While importing user data, the administrator may also assign a license to the user. Note:System administrators that plan to use ServiceWise to authenticate user logins into the ServiceWise clients must redefine the passwords of user accounts imported from an LDAP directory server. LDAP passwords are encrypted and cannot be imported into ServiceWise base projects from LDAP directory servers. System administrators must define integration settings between a ServiceWise site and an LDAP servers in the LDAP Server List, LDAP Authentication, and LDAP Sync Settings pages of the LDAP Integration folder before user accounts may be imported from an LDAP server. For more information see Administering LinkPlus Integration. To import user account attributes: 1Click the Support Member Manager icon in the tool bar. The Support Member Manager appears. 2Click the Import button. The Select a User Import Source dialog box appears. 3Select the Import from LDAP option. The Select Support Members wizard appears. 4Select an LDAP Server from the LDAP Server dropdown list. ServiceWise must be integrated with an LDAP server, otherwise no options are displayed in the LDAP Server dropdown list. The system administrator may configure Page 24 of 145 ServiceWise integration with multiple LDAP servers using the LDAP Information Setting manager. For more information see Administering LDAP Integration. 5 Optional: To search for user accounts based on the first name of the user, enter a query string in the First Name control. To filter user accounts based the first name of the user, the appropriate LDAP attribute must be mapped to the ServiceWise First Name field. For example, the ServiceWise First Name field may be mapped to the LDAPgivenName attribute. For more information see Defining Project Member Matching Identifiers. System administrator may use the asterisk * wild card character to search for text strings in the First Name control. For more information on LDAP user account attribute

25 3Select the Import from LDAP option. The Select Support Members wizard appears. 4Select an LDAP Server from the LDAP Server dropdown list. ServiceWise must be integrated with an LDAP server, otherwise no options are displayed in the LDAP Server dropdown list. The system administrator may configure ServiceWise integration with multiple LDAP servers using the LDAP Information Setting manager. For more information see Administering LDAP Integration. 5 Optional: To search for user accounts based on the first name of the user, enter a query string in the First Name control. To filter user accounts based the first name of the user, the appropriate LDAP attribute must be mapped to the ServiceWise First Name field. For example, the ServiceWise First Name field may be mapped to the LDAPgivenName attribute. For more information see Defining Project Member Matching Identifiers. System administrator may use the asterisk * wild card character to search for text strings in the First Name control. For more information on LDAP user account attribute searches see Filtering User Accounts in the LDAP Import Wizard. 6 Optional: To search for user accounts based on the last name of the user, enter a query string in the Last Name control. To search for user accounts based on the last name of the user, the appropriate LDAP attribute must be mapped to the ServiceWise Last Name field. For example, the Last Name field may be mapped to thesn attribute.for more information see Defining Project Member Matching Identifiers. System administrator may use the asterisk * wild card character to search for text strings in the Last Name control. For more information on LDAP user account attribute searches see Filtering User Accounts in the LDAP Import Wizard. 7 Optional: To search for user accounts based on any LDAP user account attribute, enter a query string in the Search Filter control. The query string entered in the Search Filter must identify both theattributeand theattribute value. For example, the querysn=smith returns all LDAP user accounts with the last name Smith. System administrators may define complex queries using four logical operators in the Search Filter control: The asterisk wildcard character, the ampersand & AND operator, the pipe OR operator, and the exclamation point! NOT operator. For more information on LDAP user account attribute searches see Filtering User Accounts in the LDAP Import Wizard. 8Click the Search button. Data matching the search parameter defined is displayed in the LDAP Users list. 9Add or remove users to the Selected Users list. Click the Add button to move users from the LDAP Users list to the Selected Users list. Click the Remove button to move users from the Selected Users list to the LDAP Users list. 10Click the Next button. The Select Users to be Overwritten page appears. 11 Optional:To overwrite properties of existing user accounts with their mapped LDAP attributes, select one or more user accounts. Any LDAP user accounts that match existing ServiceWise user accounts based on administrator-defined matching identifiers is displayed in the Select Users to beoverwritten page. For more information see Defining Project Member Matching Identifiers. 12Click the Next button. The License Assignment page appears. 13Select one or more user accounts in the User list and click the Assign License button. The Select a License Type dialog box appears. 14Assign appropriate licenses to the user. 15Click the OK button. The Select a License Type dialog box closes. 16Click the Finish button. The user accounts are imported into the ServiceWise base project Filtering User Accounts in the LDAP Import Wizard The LDAP Import wizard enables system administrators to search for and import LDAP user accounts from a directory server and into the base project of a ServiceWise site. System administrators may filter the user accounts displayed in the LDAP Users list by defining search criteria based on LDAP user account attributes. in the First Name control, Last Name control, and Search Filter control in the LDAP Import wizard The First Name and Last Name controls enable administrators to define simple queries based on the name of the user. To search for LDAP user accounts by name, the appropriate LDAP user account attributes must be mapped to the ServiceWise First Name and Last Name fields. For more information see Defining Project Member Matching Identifiers on page 84. The Search Filter control enables administrators to define complex queries based on any user account LDAP attribute. System administrators may define complex search criteria in the Search Filter control based on user account attributes. System administrators may use four characters to define user account search parameters: The asterisk* character represents the wildcard character and may be used to search for text strings in the First Name, Last Name, and Search Filter controls. The ampersand & character represents the AND operator and may be used to define complex queries in the Search Filter control. The pipe character represents the OR operator and may be used to define complex queries in the Search Filter control. The exclamation point! character represents the NOT operator and may be used to define complex queries in the Search Filter control. Wildcard character The asterisk (*) character may be used to represent any number of characters in a search string. To search for all user accounts that have a last name (surname) that begins with the lettera, enter the query string sn=a* in the Search Filter control. AND operator The ampersand (&) character represents the AND operator and may be used to search for user accounts based on multiple criteria. The AND operator may establish a relationship between two attribute-attribute value pairs. To search for user accounts that have a organization attribute value ofabcsoftwareand a country attribute value ofusa, enter the query string (&(o=abcsoftware) (co=usa)) in the Search Filter control. The query string returns only those LDAP user accounts that match both organization attribute and the country attribute criteria. OR operator The pipe ( ) character represents the OR operator and may be used to search for user accounts based on multiple criteria. Unlike the AND operator which returns that both criteria are met, a user account that matches either of the criteria in an OR query string is returned. To search for user accounts that have a organization attribute value ofabcsoftwareor a country attribute value ofusa, enter the query string ( (o=abcsoftware) (co=usa) in the Search Filter control. The query string returns all LDAP user accounts that match either of these criteria. All users in the United States or users working for ABCSoftware regardless of their country. NOT operator The exclamation point (!) character represents the NOT operator and may be used to filter out user accounts based on user account attributes or attribute values. To search for all user accounts that do not have a StreetAddress attribute, enter the query string(!(stree=*)) in the Search Filter control. 3.4 Administering System Team Groups A system team group is an administrator-defined group of users that enables the administrator to represent internal structure of the company for example, product divisions or geographic divisions, to manage company addresses, and to define team assignment and autoassignment rules. System team groups have two major functions in ServiceWise projects: System team groups represent and organize the structure of the company in a ServiceWise site. System team groups enable system administrators to define and manage company addresses. System team groups define team assignment and autoassignment rules in ServiceWise projects. Project administrators may use system team groups to ensure that employees are only assigned to appropriate project members by designating applicable system team groups Creating System Team Groups System administrators may create new system team groups whenever they create or edit a user account. The System Team Group manager enables administrators to define addresses for each system team group. System team groups are defined at the system-level. System team group definitions apply to every work project in a ServiceWise site. To create a system team group: 1 Open the Support Member Manager. Select the Support Member Manager command in the Tool menu. Click the Support Member Manager icon in the tool bar. Page 25 of 145 The Support Member Manager appears. 2 Open the Member Information page. To create a new user account and assign that account to a system team group, click the New button. To edit an existing user account and assign that account to a system team group, select the user account in the User List window and click the

26 ensure that employees are only assigned to appropriate project members by designating applicable system team groups Creating System Team Groups System administrators may create new system team groups whenever they create or edit a user account. The System Team Group manager enables administrators to define addresses for each system team group. System team groups are defined at the system-level. System team group definitions apply to every work project in a ServiceWise site. To create a system team group: 1 Open the Support Member Manager. Select the Support Member Manager command in the Tool menu. Click the Support Member Manager icon in the tool bar. The Support Member Manager appears. 2 Open the Member Information page. To create a new user account and assign that account to a system team group, click the New button. To edit an existing user account and assign that account to a system team group, select the user account in the User List window and click the Edit button. The Member Information page appears. 3 Click the New button. The System Team Group manager appears. 4 Define basic information in the Info tab. 5 Click the OK button. 6 Optional: To edit or delete a System Team Group, click the Edit or Delete buttons Assigning Users System Team Groups System administrators may assign a user account to one or more system team groups whenever they create or edit a user account in the General tab of the Member Information page. To assign a user to a system team group: 1 Click the Support Member Manager icon in the tool bar. The Support Member Manager appears. 2 Open the Member Information page. To create a new user account and assign that account to a system team group, click the New button. To edit an existing user account and assign that account to a system team group, select the user account in the User List window and click the Edit button. The Member Information page appears. 3 Select one or more system team groups in the Member of System Team Group list. System team groups are project-independent and a user account may belong to one or more system team groups. 4 Select an option from the Primary Group dropdown list. The option selected represents the default address assigned to the user account. 5 Select an option from the Time Zone dropdown list. The option selected represents the default time zone assigned to the user account. 3.5 Administering User Logins The Login Manager displays high-level information about the project members that are logged into ServiceWise work projects including the login name, the login time, the project, the client application (Windows client or Web client), and the machine name (Windows client) or IP address (Web client). System administrators may use the Login manager to view which users are logged into which ServiceWise projects, and log those users off projects. Figure 3-5: Login Manager The Login Manager displays the following user login data for all project members that are logged into the ServiceWise site: their login names, the projects that they are logged into, the time that they logged into the projects, their full names, phone numbers, addresses, license types, last active times, license release times, and the machine that they logged in from. To filter users by project: 1Access the Login Manager. The Login Manager is accessible by two methods. Select the Login Manager in the General Settings folder. Click the Login Manager icon button in the tool bar. 2Select a project from the Project dropdown list. System administrators may use the Project dropdown list to filter the users displayed in the Login Status list. The Login Status list displays all of the project members currently logged into the selected project. To log off ServiceWise users: 1Access the Login Manager. The Login Manager is accessible by two methods. Select the Login Manager in the General Settings folder. Click the Login Manager icon button in the tool bar. 2Select one or more users in the Login Status list. System administrators may use the SHIFT or the CTRL keys to select multiple users. 3Click the Logoff button. Once the system administrator logs a user off the ServiceWise system, the user has five minutes to log off. A warning message appears in the screen of the client reminding users to save their work. 3.6 Administering User Licensing TechExcel offers many different varieties licenses to businesses that purchase ServiceWise software. The licenses purchased determine the features available to users to ServiceWise applications. System administrators may define a user licensing settings whenever they create or edit a user account in the Support Member Manager. System administrators may define the license assigned to each user account. System administrators may assign one of three license types to each user account. Page 26 of 145 The license type assigned to a user determines which projects they may access and the privileges they may have in each project. The No License (Inactive User) option indicates that the user is not an active ServiceWise user and may not log into any ServiceWise project. A single product license entitles the user to access a single ServiceWise application. A light license entitles the user to access ServiceWISE projects. Users with this license class have restricted privileges and may not own incidents. For more information on privileges available users holding a light license see Understanding Light License Access Controls on page 119.

27 Once the system administrator logs a user off the ServiceWise system, the user has five minutes to log off. A warning message appears in the screen of the client reminding users to save their work. 3.6 Administering User Licensing TechExcel offers many different varieties licenses to businesses that purchase ServiceWise software. The licenses purchased determine the features available to users to ServiceWise applications. System administrators may define a user licensing settings whenever they create or edit a user account in the Support Member Manager. System administrators may define the license assigned to each user account. System administrators may assign one of three license types to each user account. The license type assigned to a user determines which projects they may access and the privileges they may have in each project. The No License (Inactive User) option indicates that the user is not an active ServiceWise user and may not log into any ServiceWise project. A single product license entitles the user to access a single ServiceWise application. A light license entitles the user to access ServiceWISE projects. Users with this license class have restricted privileges and may not own incidents. For more information on privileges available users holding a light license see Understanding Light License Access Controls on page 119. A suite license entitles the user to access all work projects in any ServiceWise project. The license classes and license types available are restricted by the ServiceWise edition purchased Loading ServiceWise Licenses System administrators may update product licenses, view a list applications, modules, and services covered by the current license, and view the availability of license classes in the License Manager Figure 3-6: License Manager The License Manager enables administrators to manage every user seat in a ServiceWise implementation. The License Manager is divided into four areas: The Runtime ID control enables the administrator to load ServiceWise licenses. The Product Type area displays a list of the ServiceWise applications, modules, and services that are covered by the current license. The License area displays the license type and edition purchased. The License Type area displays the number of licenses purchased and used of each license type. To load licenses: 1Select the License Manager page in the Admin Tree window of the System Settings project. 2The License Manager is only accessible in the System Settings project. The License Manager appears. 3Click the Update button. The Open dialog box appears. 4Locate the license file on the local directory. 5Click the Open button. 3.7 Managing Administrator Account Types and Access Controls In ServiceWise, system administrators are responsible for the creation and defintion of administrator account types and for the assignment of those account types to licensed user accounts. An administrator account type defines the role assigned to a user the privileges and responsibilities in a ServiceWise project or site. A user must be assigned an administrator account type to administer a ServiceWise sites or project. Once assigned a system administrator account type, a project member may perform all of the administrative tasks granted to that system administrator account type. In ServiceWise, a user account may be assigned three different types of administrator account types in a ServiceWise project. Asystem administrator account typeenables a project member to create and manage base and work projects and to configure system-level settings in a ServiceWise site. Abase project administrator account typeenables a project member to access and configure a ServiceWise base project. Awork project administrator account typeenables a project member to access and configure a ServiceWise work project. All administrator account types are defined by a system administrator in the Administration Account Types folder of the System Settings project. Administrator account type administrative tasks include: Creating System Administrator Account Types Understanding System Administrator Access Controls Defining Base Project Administrator Account Types Understanding Base Project Administrator Access Controls Defining Work Project Administrator Account Types Creating System Administrator Account Types A system administrator account type enables a licensed user account to perform system-level administrative tasks in a ServiceWise site. Chapter 4 System-Level Tool Administration 4 Chapter 4 -- System-Level Tool Administration This chapter introduces administrative tools and describes general system-wide maintenance tasks. Topics covered include the configuration and maintenance of the ServiceWise Document Server, ServiceWise Mail Server, and TechExcel Search Engine. Also covered are LinkPlus and LDAP integration. In this chapter: Administering the ServiceWise Document Server Administering Error Handling Administering LinkPlus Integration Administering System Messages Administering System Time Zones and Time and Date Formats Administering CTI Integration Administering the TechExcel Search Engine Managing ServiceWise Admin Reports 4.1 Administering the ServiceWise Document Server TheServiceWise Document Serverenables support organizations to upload and download files to the project knowledge base, to attach knowledge items to support incidents, and to access all project knowledge including file attachments, attachments, and knowledge documents. Page 27 of 145 ServiceWise Document Server configurations enable ServiceWise projects to locate the external document server and to download or upload knowledge items. ServiceWise Document Server administration is a three step process: The ServiceWise Document Server talks to the ServiceWise Application Server and the ServiceWise Web Server through a TCP/IP connection. Administrator-defined ServiceWise Document Server settings apply to every project in the ServiceWise site.

28 Administering System Messages Administering System Time Zones and Time and Date Formats Administering CTI Integration Administering the TechExcel Search Engine Managing ServiceWise Admin Reports 4.1 Administering the ServiceWise Document Server TheServiceWise Document Serverenables support organizations to upload and download files to the project knowledge base, to attach knowledge items to support incidents, and to access all project knowledge including file attachments, attachments, and knowledge documents. ServiceWise Document Server configurations enable ServiceWise projects to locate the external document server and to download or upload knowledge items. ServiceWise Document Server administration is a three step process: The ServiceWise Document Server talks to the ServiceWise Application Server and the ServiceWise Web Server through a TCP/IP connection. Administrator-defined ServiceWise Document Server settings apply to every project in the ServiceWise site. ServiceWise Document Server administrative tasks include: Configuring the ServiceWise Document Server Viewing the Document Root Directory Configuring Web Server Access to the Document Server Configuring Client Access to the Document Server Configuring the ServiceWise Document Server Administrator-defined ServiceWise Document Server configurations enable ServiceWise projects to locate the external document server so that project members may manage project knowledge using the ServiceWise Windows and Web clients. System administrators may configure the ServiceWise Document Server in the Document Server Setting page of the General Settings folder. TechExcel recommends configuring the TechExcel ServiceWise Document Server using TCP/IP settings. System administrators must define ServiceWise Document Server properties: The server name (or IP address) is the exact name or IP address of the computer where the document server resides. The port number represents the port number used by the document server. The default port number is To configure the ServiceWise Document Server: 1Select the System Setting project in the Project dropdown list of the tool bar. 2Select the Document Server Setting page in the General Settings folder. The Document Server Setting page appears. 3Select the Support Document Server (TCP/IP access) check box. 4Enter the IP address or the name of the server machine that hosts the ServiceWise Document Server in the Server Name edit box control. 5Enter the port number in the Port Number edit box control. The port number is defined when the administrator installs the ServiceWise Document Server. The default port number is Optional: To test the connection to the ServiceWise Document Server, click the Check Connection button. If the connection is successful, a confirmation dialog box appears and the read-only Document Root Directory control displays the location of the project Document Root Directory Viewing the Document Root Directory The document root directory is a directory where all project documents are stored. The Document root directory is defined during the installation of the ServiceWise Document Server. The Document Root Directory control in the Document Server Setting page is a read-only field that is automatically populated when a connection is established between the ServiceWise Admin client and the ServiceWise Document Server Configuring Web Server Access to the Document Server TheServiceWise Web Serveris an optional application that enables ServiceWise project members to access ServiceWise projects through an intranet or the Internet. To enable project members using ServiceWise Web to upload, download, and access project knowledge, the system administrator must identify the location of the ServiceWise Document Server so that it can be found by the ServiceWise Web Server. The ServiceWise Web Server may access the ServiceWise Document Server by three methods: Direct access by a local path Direct access by a network path TCP/IP access To configure Web Server Access to the Document Server: 1Select the System Setting project in the Project dropdown list of the tool bar. 2Select the Document Server Setting page in the General Settings folder. The Document Server Setting page appears. 3Select and define the method by which the ServiceWise Web Server accesses the ServiceWise Document Server. To enable access by a local path, select the Direct Access Through the Following Local Path radio button and define the path in the edit box. To enable access by a network path, select the Direct Access Through the Following Network Path radio button, click the Browse button, and locate the path in the custom browser. To enable access by a TCP/IP connection, click the TCP/IP Access radio button Configuring Client Access to the Document Server To enable project members using the ServiceWise Windows client to upload, download, and access project knowledge, the system administrator must identify the location of the ServiceWise Document Server so that it can be found by the ServiceWise clients. The ServiceWise Web Server may access the ServiceWise Document Server by two methods: Direct access by a network path TCP/IP access To configure Client Access to the Document Server: 1Select the System Setting project in the Project dropdown list of the tool bar. 2Select the Document Server Setting page in the General Settings folder. The Document Server Setting page appears. 3Select and define the method by which the ServiceWise Windows clients accesses the ServiceWise Document Server. To enable access by a network path, select the Direct Access Through the Following Network Path radio button, click the Browse button, and locate the path in the custom browser. To enable access by a TCP/IP connection, click the TCP/IP Access radio button. 4.2 Administering Error Handling ServiceWise error handling enables system administrators to track and diagnose problems with incoming and outgoing notifications. All error handing settings are defined in the System Settings project. System-level settings apply to all project in a ServiceWise site. retrieval and notification settings are defined separately. The Retrieval page enables system administrators to define rules for managing incoming errors. The Notification page enables system administrators to define rules for managing outgoing errors. Page 28 of 145

29 4.2 Administering Error Handling ServiceWise error handling enables system administrators to track and diagnose problems with incoming and outgoing notifications. All error handing settings are defined in the System Settings project. System-level settings apply to all project in a ServiceWise site. retrieval and notification settings are defined separately. The Retrieval page enables system administrators to define rules for managing incoming errors. The Notification page enables system administrators to define rules for managing outgoing errors. Figure 4-1: Retrieval Page Using the Retrieval page and the Notification page in the System Setting page, system administrators may define general settings including trace levels for notification errors, create error logs, and define notification service messages Defining General Error Tracking Settings System administrators may define general mail error handling settings using tools in the Mail Notification Service Error Handling Setting manager. General settings include the trace level and service settings. trace levels determine the types of messages that are logged when errors occur. System administrators may choose one of three trace settings: The Info, Warning, and Error trace level The Warning and Error trace level The Error trace level service settings determine the sensitivity of the notification service. notification may either continue to operate when an error occurs, or stop. System administrators may choose between two service settings: The Continue Running the Service with Log Messages service level The Stop Service when Error Occurs service level To define general settings: 1Select the Mail Notification page. The Mail Notification page appears. 2Select an option from the Trace Level dropdown list. 3Select an option from the Service Setting dropdown list Creating Log Files System administrators may enable ServiceWise to write error messages to a log file and define the name of that log file using tools in the Mail Notification Service Error Handling Setting manager. To create log files: 1Select the Retrieval page. 2Select the Enable to Write Error Messages to Log File check box. 3Define the name of the log file in the Log File Name field Define Service Messages System administrators may enable notification of service messages and define service message properties using tools in the Mail Notification Service Error Handling Setting manager. notification service messages are delivered when handling error occur with the notification service. The SMTP server name Require authentication recipient and sender addresses The log level The time interval To define service messages: 1Select the Retrieval page in the Mail Error Handling folder in the System Settings view of the ServiceWise Admin client. 2Select the Notification of Service Messages check box. 3Define the name of the SMTP server in the SMTP Server Name field. 4 Optional:To require user authentication, select the Require User Authentication check box and enter the user name and password. 5Define the address for service message recipients in the Recipients field. 6Define the address for service message senders in the Senders field. 7Select an option from the Log Level dropdown list. 8Select an option from the Time Interval for Sending Log dropdown list Defining Service Error Reports System administrators may use the Notification Error Service Handling Setting manager to define notification error reports. If an notification message is not delivered to any selected recipients, the sender automatically receives an error report and attachment that explains why the notification was not delivered. System administrators can define the recipient, sender, the level of detail, and the time interval of the service error report in the Notification Error Service Handling Setting manager. To define error report settings: 1Select the Retrieval page in the Mail Error Handling folder in the System Settings view of the ServiceWise Admin client. 2Inthe General Settings area, define the Trace Level and Mail Service Setting. 3Inthe Message Log Setting, select the Enable to write mail messages to a log file and name the log file in the Log File Name field. 4Click the Enable notification service messages check box. 5Define the SMTP Server Name. 6Enter the address of the error report recipient in the Recipient Address field. 7Enter the address of the error report sender in the Sender Address field. 8Select the scope of the error report by selecting an option from the Log Level dropdown list. 9Select a time interval for the error report s by selecting an option from the Time Interval for Sending log dropdown list. 10Select the OK button. 4.3 Administering LinkPlus Integration TechExcel LinkPlus enables businesses to write and retrieve employee, customer, contact, incident, and event data to and from TechExcel ServiceWise or TechExcel Page 29 ofbusiness 145 CustomerWise projects, synchronize data between these TechExcel applications and third-party business applications, and integrate either application with third-party solutions. TechExcel LinkPlus enables bi-directional data synchronization between TechExcel CustomerWise or Tech Excel ServiceWise and third-party applications and database servers. LinkPlus enables businesses to develop integrated custom applications that extend the power of TechExcel employee, customer, contact, incident, and event management to third-party applications.

30 6Enter the address of the error report recipient in the Recipient Address field. 7Enter the address of the error report sender in the Sender Address field. 8Select the scope of the error report by selecting an option from the Log Level dropdown list. 9Select a time interval for the error report s by selecting an option from the Time Interval for Sending log dropdown list. 10Select the OK button. 4.3 Administering LinkPlus Integration TechExcel LinkPlus enables businesses to write and retrieve employee, customer, contact, incident, and event data to and from TechExcel ServiceWise or TechExcel CustomerWise projects, synchronize data between these TechExcel applications and third-party business applications, and integrate either application with third-party business solutions. TechExcel LinkPlus enables bi-directional data synchronization between TechExcel CustomerWise or Tech Excel ServiceWise and third-party applications and database servers. LinkPlus enables businesses to develop integrated custom applications that extend the power of TechExcel employee, customer, contact, incident, and event management to third-party applications. LinkPlus enables businesses to integrate their TechExcel ServiceWise or CustomerWise projects with third-party business software. Organizations that have an existing customer management system or other business software may use LinkPlus to integrate that solution with TechExcel CustomerWise or ServiceWise. Key LinkPlus components include: TheLinkPlus web serviceis a collection of library of customer management functions that enable businesses to integrate their CustomerWise marketing, sales, and support projects or ServiceWise support projects with third-party business applications to better manage employee, customer, contact, and incident data. TheLinkPlus synchronization serviceis a service that enables the bidirectional synchronization of data between TechExcel ServiceWise or TechExcel CustomerWise and other business applications. TheLinkPlus SDKis a software development kit for creating and integrating custom applications that enable businesses to manage ServiceWise employee data or CustomerWise customer data though LinkPlus web services. For more information please see thelinkplus Web Service Guideor contact TechExcel. 4.4 Administering System Messages System administrators may create two different types of system messages: Welcome messages are displayed in the Project to Login dialog box and may be used to provide project members with system-level information. Administrator-defined welcome message is the default message in the login screen. Warning messages are displayed in the Project to Login dialog box and override the welcome message. Each warning message has a broadcast period and automatically overrides the welcome message and appears in the login screen for the duration of its broadcast period. System administrator may use the System Message command to create and manage messages that are broadcast to all ServiceWise users. System messages may be used to communicate information to every ServiceWise user regardless of project membership. TechExcel ServiceWise supports two types of system messages: project selection messages and system warning messages. System message management tasks include: Defining System Welcome Messages Defining System Warning Messages Managing User Sessions Defining System Welcome Messages System administrators may use the System Message dialog box to define system-wide welcome messages. Welcome messages enable administrators to communicate critical information to ServiceWise users across all projects. After logging in to the application, TechExcel ServiceWise windows client users are taken to a project selection dialog box, while Web users are taken to a home page displaying all available projects. Administrator may create welcome messages that are displayed on either screen to display a company specific message, or disseminate critical information to all users. To define welcome messages: 1Select the Project Selection page in the System Message folder in the System Settings view of the ServiceWise Admin client. The System Message page appears. 2Enter a message in the Message for ServiceWise Web (in HTML) text area. 3Enter a message in the Message for ServiceWise Client (in TEXT) text area. The format the message using standard HTML markup tags. 4Click the OK button Defining System Warning Messages System administrators may use the System Warning dialog box to define system-wide warning messages. Warning messages enable administrators to communicate critical information to ServiceWise users across all projects. Organizations may occasionally plan to take their ServiceWise project offline to perform system or database maintenance. System administrators may notify users of the scheduled down time system warning messages. For each warning message administrators must define a beginning and ending date and time. The warning system message is broadcast to all ServiceWise users in all projects for the duration of the administrator-defined broadcast period. During the broadcast period the system warning message replaces the welcome message in the project selection page. When the broadcast period is over, the welcome message returns to the page. Note:Companies may occasionally plan to take the ServiceWise system offline to perform system or database maintenance. System administrators may use warning messages to alert ServiceWise users prior to an upgrade and provide them with the chance to plan their work around the system downtime. To define system warning messages: 1Select the System Warning page in the System Message folder in the Admin tree window of the System Settings view in the ServiceWise Admin client. The System Warning page appears. 2Define the warning message. Enter a message in the Message for ServiceWise Web (in HTML) text area. Enter a message in the Message for ServiceWise Web (in Text) text area. 3Select the Display message at project selection page check box. 4Choose the beginning time and date in the Date/Time From control. 5Choose the ending time and date in the Date/Time To [control]. 6To automatically log users off the system, select the Log Off the User from the System check box. All ServiceWise client users are automatically logged off the ServiceWise system at the time and date defined in this page. ServiceWise users cannot access their ServiceWise projects for the duration of the outage. 7Choose the beginning time and date in the Date/Time From [control]. 8Choose the ending time and date in the Date/Time To [control]. 9Click the OK button Managing User Sessions An organization may occasionally plan to take the ServiceWise system offline to perform system or database maintenance. ServiceWise enables administrators to communicate and manage ServiceWise client users during an upgrade. The Warning System Message Manager enables project administrators to remind project members of the scheduled downtime and automatically log off users at a specified time. The Login Manager enables project administrators to view the current login status and login history of all DevTest project members and to manually log off ServiceWise client users. ServiceWise Admin provides system administrators with two methods for managing user sessions: Automatically log all users off the system using tools in the Warning System Message Manager. Manually log users off the system using the Login Manager. For more information see Administering User Logins on page Administering System Time Zones and Time and Date Formats Project administrators may define the time zones ServiceWise projects using the Time Zone & Date Format page in the System Settings project. The System Time Zone tab enables system administrator to define the system time zone settings for all projects in a ServiceWise site. System administrators may choose to mandate that all project members and employees use administrator-defined time zone settings. Time zones may be defined both at the system level and at the project level. If the administrator does not mandate that the system time settings are used in a project, project administrators may define time zone settings for their projects individually. To define project time zone settings: 1Select the Time Zone & Date Format page in the Admin Tree window of the System Setting project. Page 30 of 145 System time zone settings may be defined in the System Setting project only. 2Select the System Time Zone tab. 3Select an option in the Default Time Zone dropdown list. 4 Optional:To allow for daylight savings time, select the Adjust for Daylight Savings Changes check box. 5Define time zone options for project members and employees.

31 4.5 Administering System Time Zones and Time and Date Formats Project administrators may define the time zones ServiceWise projects using the Time Zone & Date Format page in the System Settings project. The System Time Zone tab enables system administrator to define the system time zone settings for all projects in a ServiceWise site. System administrators may choose to mandate that all project members and employees use administrator-defined time zone settings. Time zones may be defined both at the system level and at the project level. If the administrator does not mandate that the system time settings are used in a project, project administrators may define time zone settings for their projects individually. To define project time zone settings: 1Select the Time Zone & Date Format page in the Admin Tree window of the System Setting project. System time zone settings may be defined in the System Setting project only. 2Select the System Time Zone tab. 3Select an option in the Default Time Zone dropdown list. 4 Optional:To allow for daylight savings time, select the Adjust for Daylight Savings Changes check box. 5Define time zone options for project members and employees. System administrators may mandate that all project members and all employees use the administrator-defined system time zone. Enforce all team members to use system time zone Enforce all employees to use system time zone 6 Optional:To define how time is saved in the database, click the Change Option button. In the Time Saved to Database Option dialog box, select an option. System Time Zone Greenwich Mean Time 7Click the OK button Defining Date and Time Formats Project administrators may define system time and date formats using the Time Zone & Date Format Setting control in the Project Properties page. System date and time format represent the default formats used to display dates and times in a ServiceWise site. System administrators may choose to mandate that all project members and employees use administrator-defined time and date format. Date and time formats may be defined both at the system level and at the project level. If the administrator does not mandate that the system date and time formats are used in the ServiceWise implementation, project administrators may define time and date formats for their projects individually. To define project date and time zone settings: 1Select the Time Zone & Date Format page in the Admin Tree window of the System Setting project. System time zone settings may be defined in the System Setting project only. 2Select the System Date/Time Format tab. Note:Any changes made to the date format require that the web server be stopped and restarted for the change to be visible in the ServiceWise Web clients. System administrators may reload web settings by clicking the Reload button in the tool bar. 3Define date and time formatting. Select a formatting option from the Date Format dropdown list. Select a formatting option from the Time Format dropdown list. 4Define time and date format options for project members and employees. System administrators may mandate that all project members and all employees use administrator-defined time and date formats. Enforce all team members to use system time and date formats Enforce all employees to use system time and date formats Defining System Daylight Savings Settings Project administrators may enable daylight savings and define beginning and ending hours in the Daylight Savings tab of the Time Zone & Date Format page in the System Setting project. 4.6 Administering CTI Integration Computer telephony integration, or CTI, is a technology that enables telephone and computer systems to be integrated or coordinated. TechExcel ServiceWise CTI tools enable support teams to improve customer support over the telephone through the CTI Data Connector (CDC) from Mirage Computer Systems. ServiceWise CTI integration offers support organizations inbound and outbound calling features designed to improve efficiency. On-screen dialing of outgoing phone numbers from the TechExcel ServiceWise client improves support efficiency. Project members may dial employees by selecting phone numbers in the ServiceWise client. Automatic on-screen display of caller data for all inbound calls. PRoject members can immediately see who is calling and do not need to look up employee names and service history. On-screen caller ID of incoming and outgoing phone calls. ServiceWise CTI automatically matches incoming and outgoing calls with phone numbers stored in the base project. ServiceWise CTI integration requires the purchase of the CTI Data Connector from Mirage Computer Systems Installing and Configuring CDC for ServiceWise Integration TechExcel ServiceWise offers CTI features through the CTI Data Connector TechExcel Edition from Mirage Computer Systems. The CTI Data Connector TechExcel Edition is a plug-and-play solution especially developed to work with TechExcel ServiceWise and TechExcel ServiceWise. The CTI Data Connector (CDC) responds to all incoming and outgoing calls in background mode. To configure ServiceWise CTI features, a system administrator must first install and configure the CTI Data Connector TechExcel Edition from Mirage Computer Systems and install an executable and XML file from TechExcel. Required components include: Mirage CTI Data Connector TechExcel Edition HDpop-up.exe cdc.xml file The CTI Data Connector TechExcel Edition and the CTI Data Connector license are both available from Mirage. The ServiceWise CTI program (HDpopup.exe) and the cdc.xml file are available for download from TechExcel. To install and configure CDC for ServiceWise integration: 1Run the cdckernel.exe to install the CTI Data Connector. The CTI Data Connector is installed to C:\Program Files\CTI Data Connector by default. 2Configure the CTI Data Connector. System administrators may configure the CTI Data Connector using the CTI Data Connector Configuration Wizard. For step-by-step instructions installing the CTI Data Connector see documentation from Mirage Computer Systems. 3Add the CTIData.dll to the ServiceWise web server. The default location for ServiceWise scripts: C:\Inetpub\scripts\texcel\ServiceWise 4Copy the cdc.xml to the \CTI Data Connector folder. 5Copy the HDpop-up.exe file to the \CTI Data Connector folder. 6Edit the cdc.xml file to point to the HDpop-up.exe. The name of the pop-up executable must match the name of the executable defined in the cdc.xml file. System administrators have two options: Rename the HDpop-up.exe to pop-up.exe, matching the name in the cdc.xml file. Open the cdc.xml file in Notepad and edit the file so that it points to the HDpop-up.exe. Page 31 of 145 7Double-click and run the HDpop-up.exe.

32 The default location for ServiceWise scripts: C:\Inetpub\scripts\texcel\ServiceWise 4Copy the cdc.xml to the \CTI Data Connector folder. 5Copy the HDpop-up.exe file to the \CTI Data Connector folder. 6Edit the cdc.xml file to point to the HDpop-up.exe. The name of the pop-up executable must match the name of the executable defined in the cdc.xml file. System administrators have two options: Rename the HDpop-up.exe to pop-up.exe, matching the name in the cdc.xml file. Open the cdc.xml file in Notepad and edit the file so that it points to the HDpop-up.exe. 7Double-click and run the HDpop-up.exe. The CTI Data Connector page appears. 8Right-click the CTI Data Connector icon in the top-left corner of the CTI Data Connector page, and select the Settings command in the shortcut menu. The CTI Setting dialog box appears. 9Define the location of the ServiceWise Web Server. The default ServiceWise URL: 10Click the OK button. Once the administrator has installed and configured CDC to work with ServiceWise, the system and project administrators may configure ServiceWise CTI integration settings in the ServiceWise Admin client. Configure system-level CTI integration in the System Settings project of the ServiceWise Admin client. Configure project-level CTI integration in the ServiceWise Admin client System-Level Integration Configuration ServiceWise CTI integration must be enabled at both the system and project levels in the ServiceWise Admin client. System administrators may enable data connector integration and define the hot key for all outgoing calls in the CTI Integration page of the CTI Integration folder of the System Settings project. System-level CTI integration configuration tasks include: Enabling CTI Integration Enabling and Defining Keyboard Shortcuts for Outgoing Calls Enabling CTI Integration System administrators may enable CTI integration in the General Settings page of the CTI Integration folder of the System Settings project. To enable CTI integration in a ServiceWise site, select the Enable CTI Data Connector Integration button in the General Settings page of the CTI Integration folder in the System Settings project Enabling and Defining Keyboard Shortcuts for Outgoing Calls Keyboard shortcuts are a combination of keystrokes that perform a predefined function. Each keyboard shortcut consists of one or more modifier keys and a hot key. Administrator-defined outgoing phone call keyboard shortcuts enable ServiceWise project members to quickly dial employees by highlighting a telephone number in the Employee list window and pressing the predefined combination of keys. System administrators may enable and define keyboard shortcuts for outgoing calls in the General Settings page of the CTI Integration folder of the System Settings project. To enable and define hotkeys for outgoing calls: 1Select the Activate Hotkey for Outgoing Calls check box in the General Settings page of the CTI Integration folder. 2Select one or more modifier keys in the Modifier area. System administrators may choose up to three modifiers: the CTRL, ALT, and the SHIFT keys. 3Select the hotkey from the Hotkeys dropdown list. The Hotkey dropdown list displays ten options: the F1-F10 function keys. 4.7 Administering the TechExcel Search Engine The TechExcel Search Engine enables project members to search for key words and text strings in all system-defined and custom-defined multiple-line text controls. Multiple-line text box controls, also calledmemo fields, are data-entry controls that enable support organizations to conduct extended discussions about incidents, events, employees and other business objects tracked in work projects. Common multiple-line text box controls include: Description Close Note History Incident Notes Link Comments Event Description All custom-defined multiple-line text controls All multiple-line text box controls belong to the multiple-line text box control type. For more information on multiple-line text box controls see Customizing Dropdown List Controls 7. The content of all multiple-line text box controls is indexed to speed queries. System administrators may also periodically index these fields to enhance project searches. System administrators may install multiple TechExcel Search Engines in and configure settings for each ServiceWise site. Each ServiceWise project may have a unique TechExcel Search Engine or multiple projects may share the same TechExcel Search Engine. TechExcel Search Engine management tasks include: Installing the TechExcel Search Engine Configuring Search Engine Settings Indexing Multiple-selection List Controls Installing the TechExcel Search Engine System administrators may install the TechExcel Search Engine to enhance the searching capabilities of project members in ServiceWise projects. The TechExcel Search Engine runs as a service and may managed using the Services manager in Administrative Tools of a Windows operating system. The ServiceWise search service must be installed on the machinebeforea project may enable TechExcel Search Engine support and index the searchable fields in the Page 32 of 145 project. The TechExcel Search Engine should be installed on the same computer as the ServiceWise Document Server. To install the TechExcel Search Engine: 1Run the Search Setup executable. The ServiceWise Search Server Installation wizard installs the TechExcel Search Engine.

33 TechExcel Search Engine management tasks include: Installing the TechExcel Search Engine Configuring Search Engine Settings Indexing Multiple-selection List Controls Installing the TechExcel Search Engine System administrators may install the TechExcel Search Engine to enhance the searching capabilities of project members in ServiceWise projects. The TechExcel Search Engine runs as a service and may managed using the Services manager in Administrative Tools of a Windows operating system. The ServiceWise search service must be installed on the machinebeforea project may enable TechExcel Search Engine support and index the searchable fields in the project. The TechExcel Search Engine should be installed on the same computer as the ServiceWise Document Server. To install the TechExcel Search Engine: 1Run the Search Setup executable. The ServiceWise Search Server Installation wizard installs the TechExcel Search Engine. 2During the installation the administrator must: Accept the license agreement. Ensure that the TechExcel Search Engine can connect to the ServiceWise Application Server. 3The TechExcel Search Engine Configuration dialog box appears. 4Define the name of the current TechExcel Search Engine in the Referred as Service Name field. Each TechExcel Search Engine installed in a ServiceWise site may have its own name enabling administrators to differentiate between them. System administrators may choose which TechExcel Search Engine is used for each work project. Multiple projects may use the same TechExcel Search Engine. 5Define the location of the index directory. 6Click the OK button. 7Click the Finish button Configuring Search Engine Settings System administrators may enable TechExcel Search Engine support, select an appropriate TechExcel Search Engine for a project, and index the multiple-line text box controls in that project using controls in the TechExcel Search Engine page. To define TechExcel Search Engine settings: 1Select the Search Engine page in the Enterprise Edition Features folder of the ServiceWise Admin Tree window. 2Select the Enable Memo Fields Search check box. 3Click the Select a Search Engine button. The Select a Search Engine dialog box appears. 4Select a TechExcel Search Engine option in the Search Engine list. System administrators may install multiple TechExcel Search Engines in their ServiceWise site. Each ServiceWise project may have its own Search Engine or multiple projects may share the same TechExcel Search Engine. 5Click the Select button. The Select a Search Engine dialog box closes Indexing Multiple-selection List Controls System administrators may enable TechExcel Search Engine support, select an appropriate TechExcel Search Engine for a project, and index the multiple-selection list controls in that project using controls in the TechExcel Search Engine page. The TechExcel Search Engine performs search indexing on multiple-selection list controls. The first time an administrator indexes a large database, the process may take hours. Subsequent indexing of project multiple-selection list controls is only performed on newly added records and the execution time is significantly reduced. To index project multiple-selection list controls: 1Select the Search Engine page in the Enterprise Edition Features folder of the ServiceWise Admin Tree window. 2Click the Index Now button. The Initialization of Search Index dialog box appears. 3Click the Start button. The Initialization of Search Index dialog box closes. The Current Status control displays the current status of the indexing process. When indexing is complete the Current Status control displays the textindexing process finished. 4.8 Managing ServiceWise Admin Reports System administrators may use the ServiceWise Change Log Report Admin reports to view information about changes to ServiceWise implementations. System administrators may determine the scope of the report by selecting the project, user responsible for the changes, and the beginning and ending date for the report. The Admin Change Log Report displays all of the changes made to the ServiceWiseServiceWise system in a printable format. The Admin Change Log Report provides administrators with a printable report that shows all changes made to the ServiceWise system. Figure 5: Admin Change Log Report The report shows administrators when the change was made, who was responsible for the change, and what changes were made in a tabular format. Administrators may define four different parameters for each report: Project User Date From Date To To view the Admin Change Log report: 1Select the Admin Change Log Report page in the Admin Report folder of the System Setting project. The Admin Change Log Report page appears. 2Select the report parameters: Project User Date From Date To 3 Optional: To print the report, select the Print button. Chapter 5 Project-Level Project Administration 5 Chapter 5 -- Project-Level Project Administration Page 33 of 145

34 2Select the report parameters: Project User Date From Date To 3 Optional: To print the report, select the Print button. Chapter 5 Project-Level Project Administration 5 Chapter 5 -- Project-Level Project Administration In this chapter: Understanding Project Administration Managing Project Properties Managing Optional Project Features Managing Project Administrators Managing Account Types Managing Account Access Controls Managing Project Members Managing Team Groups Managing Group Folders 5.1 Understanding Project Administration Project administrators are responsible for managing project-specific properties, project GUI customizations, and assigning privileges to project members. Project administrators define what is tracked in the project, how it is tracked, and who may track the data. Project administration tasks may be broken into four inter-related areas: Project definition Incident definition and GUI customization Project member administration Workflow administration Project definition A ServiceWise implementation (site) may support multiple projects, and every project administrator is responsible for defining the scope of their projects and the nature of the incidents tracked in that project. Project scope determines what is tracked in the project, how it is tracked and who may track it. A project is a tool for managing and trackingincidents. An incident is a collection of data that represent the tasks (discreet units of work) that project members may perform in a project. The incidents manged in a project and the data represented by the incident depend on the project type. Every ServiceWise site consists of a base project and one or more work projects. Base projects are used to manage the employees that are shared by multiple work projects. Project administrators may define a unique project team, workflow rules, auto-routing rules and escalation rules for each project Incident definition and GUI customization Project administrators are responsible for customizing thegraphical user interface(gui) of the project to represent and track the incidents tracked in that project. By customizing the project GUI, the project administrator also defines what data is tracked in the project. An incident is a collection of data that is submitted, updated, and tracked in the project. Project administrators may customize and add pages and controls and define parent-child relationships between selection controls. All project customizations are manifested in the ServiceWise client Window and Web interfaces Project member administration Defining the project team and project account types. Project administrators may define all of the project members, group teams, and group folders used in the project. Project administrators are responsible for adding user accounts to a project and assigning each user account an account type that determines that project members project-level privileges. In ServiceWise all privileges are assigned toaccount typesand not to individual user accounts. User accounts are granted project-level privileges based on the account type they have in the project. Aproject memberis a user account that has been added to a project and assigned an account type by a project administrator. Team groupsrepresent teams of project members that share a common set of responsibilities within a project. Each group enables project teams to assign incidents to multiple project members who do not necessarily share the same account type. Group foldersrepresent a common repository for incidents that may be owned by multiple project members. Every group folder is owned by a group and access to the incidents contained in the group folder is protected by group-membership and account type-based access privileges. Only project members that belong to the group that owns the group folder and who have the privileges to access a group folder may view, own, and forward group folder incidents. Account types, groups, and group folders enable administrators to define flexible team representation in a project Workflow administration Project administrators are responsible for defining all project workflow rules and process automation settings including incident auto-routing, incident notification, and incident escalation. Administrator-defined workflow rules enable organizations to ensure that incidents are managed in an effective and timely manner. In ServiceWise, every incident hasone and only oneowner at every stage of the development life cycle. The owner of an incident may be an individual project member or a group folder, but current incident owner is always tracked in a project. 5.2 Managing Project Properties Although system administrators are responsible for creating ServiceWise projects and defining many project properites, project administrators may edit or update many basic project properties. System administrators are responsible for creating projects, defining the project type, and the based project. Project administrators are responsible configuring work projects to support help desk processes. In the General Project Settings folder, project administrators may define general project information and enable certain advanced features. The General Settings folder contains nine different system pages that enable project administrators to define project properties, team membership, project account types and privileges, and optional features. The Project Properties page enables project administrators to edit and update fundamental project properties. Page 34 of 145

35 Although system administrators are responsible for creating ServiceWise projects and defining many project properites, project administrators may edit or update many basic project properties. System administrators are responsible for creating projects, defining the project type, and the based project. Project administrators are responsible configuring work projects to support help desk processes. In the General Project Settings folder, project administrators may define general project information and enable certain advanced features. The General Settings folder contains nine different system pages that enable project administrators to define project properties, team membership, project account types and privileges, and optional features. The Project Properties page enables project administrators to edit and update fundamental project properties. Figure 5-1: Project Properties Page Basic project properties include the name of the project, the project description, and the incident ID prefix used. The Base Project is defined by the system administrator when the work project is created. Project administrators may not change the base project of their work project. The Project Name property defines the name of the current project. The Base Project Type is defined by the system administrator when the base project is created. Project administrators may not change the base project type of the base project. This field is editable only in base projects. The Project Type is defined by the system administrator when the project is created. All ServiceWiseServiceWise work projects belong to the ServiceWise project type. The Project Type control is not visible in base projects. The Description property defines a general description of the current project. The ID Prefix property defines a numerical or character prefix that is added to each incident ID in the project. This feature may be used so that incidents associated with a particular project are easier to identify. The ID Starting No. property defines the initial incident ID number. If an administrator enter 100 in this field, the first incident created is incident number Updating Project Names Project administrators may update the title of a project in the Project Name field of the Project Properties page. All project names are defined by system administrators when they create ServiceWise projects. When updating project names, project administrators should avoid using the following characters:/ \ :? < > Updating Project ID Prefixes Project administrators may define incident ID prefixes and incident, event, employee, contact, invoice, and support plan ID starting numbers in the Define Starting IDs manager. To access the Define Starting IDs manager, click the Starting IDs button in the Project Properites page of the General Project Settings folder in a project view of the ServiceWise Admin client. The ID Prefix control enables administrators to define a numerical or character prefix that is added to each incident ID in the project. ID prefixes make the incidents associated with a particular project easier to identify. While these IDs are posted automatically, managers may find it helpful to assign starting numbers so that certain components in the project are easier to recognize. All starting ID settings are optional. The Defining Starting ID manager is divided into three areas: the Employee/Contact area, the Incident area, and the Event and Invoice area: The ID Scope control enables administrators to define if these settings are unique to the base project, or if they should apply to the entire database. The Employee ID Starting No. control enables administrators to define a employee ID starting number. The Contact ID starting No. control enables administrators to define a contact ID starting number. The ID Prefix control enables administrators to adds a numerical or character prefix (up to four characters) to each incident ID. This feature may be used so that incidents associated with a particular project are easier to identify. The ID Starting No. control enables administrators to defines the initial incident ID number. If an administrator enters 100 in this field, the first incident created is ncident number 100. The Event ID Starting No. control enables administrators to define an event ID starting number. The Invoice ID Starting No. control enables administrators to define an invoice ID starting number. The Support Plan ID Starting No. control enables administrators to define a support plan ID starting number Making Projects Active or Inactive Project administrators to make projects active or inactive using the Active Project control in the Project Properties page. Active projects may be accessed by ServiceWise project members through the ServiceWise clients. Inactive projects cannot be accessed by ServiceWise project members and may be deleted by a system administrator Enabling Web Uploading Project administrators may enable uploading and downloading in ServiceWise projects using Support Web Uploading control in the the Project Properties page. The Support Web Uploading control enables ServiceWise Web users to upload files to the ServiceWise Document Server Enabling the Employee Web Portal Project administrators may enable support for the Employee Web Portal using the Enable Employee Web Portal control in the the Project Properties page. The Employee Web Portal enables user-defined employees to submit, view, and edit ServiceWise incidents through the Internet Support Knowledge Building in ServiceWise Web Project administrators may enable project members to build knowledge using the Enable Knowledge Building using the Web control in the the Project Properties page. If the knowledge building feature is enabled, internal project members may add, edit, and delete knowledge items in the knowledge base using their ServiceWise Web clients Enabling Web Conversions Project administrators may enable support for web conversations using the Enable Web Conversation control in the Project Properties page. Web conversation enables support project members and employees to communicate about incidents using text chat-like interface through the Web Defining the Display Format of Names Project administrators may define how the names of project members are displayed in the client GUI using the Name Display Format controls in the Project Properties page. The names of project members may be displayed using one of two formats: First name Last name Last name, First name The names of project members and employee contacts are displayed using the selected format in the User dropdown list and the Incident, Event, and Employee List windows. The First name Last name format: Page 35 of 145

36 5.2.8 Defining the Display Format of Names Project administrators may define how the names of project members are displayed in the client GUI using the Name Display Format controls in the Project Properties page. The names of project members may be displayed using one of two formats: First name Last name Last name, First name The names of project members and employee contacts are displayed using the selected format in the User dropdown list and the Incident, Event, and Employee List windows. The First name Last name format: Figure 5-2: First Name Last Name Format The Last name, First name format: Figure 5-3: Last Name, First Name Format Defining Incident Description Field Sizes Project administrators may define the size of the Description field displayed in the Incident page. The number entered determines the maximum number of characters that may be entered into this field using WebEditPro through the Web. The default size is 10K Defining Project Time Zones Project administrators may define the time zones for individual projects using the Select Time Zone and Date Format Setting manager in the Project Properties page. The Project Time Zone tab enables the project administrator to define the default time zones for project members and employees in a project and to enable daylight savings adjustments and other options. Time zone settings may be defined both at the system-level and at the project-level. System administrators may mandate that all project members and employees use administrator-defined time zone settings. To define project time zone settings: 1Click the Time Zone and Date Format Setting button in the Project Properties page. The Select Time Zone and Date Format Setting manager appears. 2Select the Project Time Zone tab. 3Select an option in the Default Time Zone for Team dropdown list. 4To allow for daylight savings time, select the Adjust for Daylight Savings Changes check box. 5Select an option in the Default Time Zone for Employees dropdown list. 6To allow for daylight savings time, select the Adjust for Daylight Savings Changes check box. 7Select a time zone option for project team members in the Time Zone Option area. Project members may choose between three options for project members: Enforce all team members to use system time zone All Team members within this project use the project time zone Team members can use own time zone preference 8To enable employees to define their own time zone settings, select the Employees Can Use Own Time Zone Preference check box. 9Click the OK button Defining Date and Time Formats Project administrators may define project-specific time zone and date formats using the Time Zone & Date Format Setting control in the Project Properties page. Date and time formats may be defined both at the system-level and at the project-level. System administrators may mandate that all project members and employees use administrator-defined system date and time formats Date Formats Project administrators may choose between 13 different date formats:. M/d/yy MM/dd/yyyy yy/mm/dd yyyy/mm/dd yyyy-mm-dd dd-mmm-yy dd/mmm/yyyy dd/mm/yy dd/mm/yyyy dd.mm.yy dd.mm.yyyy dd-mm-yy dd-mm-yyyy Time Formats h:mm:ss am/pm hh:mm:ss am/pm H:mm:ss HH:mm:ss To define project date and time formats: 1Click the Time Zone and Date Format Setting button in the Project Properties page. The Select Time Zone and Date Format Setting manager appears. 2Select the Project Date/Time Format tab. Note:A n y changes made to the date format require that is be stopped and restarted for the change to be visible in the ServiceWise Web clients. 3Define date and time formatting for project members. Select a formatting option from the Date Format dropdown list. Select a formatting option from the Time Format dropdown list. 4Define date and time formatting for employees Select a formatting option from the Date Format dropdown list. Select a formatting option from the Time Format dropdown list. 5Select time and date format options for project team members in the Date/Time Format Option area. Project members may choose between three options for project members: Enforce all team members to use system time zone All team members within this project use the project Date/Time Format Team members can use own time format preference 6To enable employees to define their personal time and date format preferences, select the Employees Can Use Own Time Format Preference check box. 7Click the OK button Managing ServiceWise Windows Client Sessions Project administrators may define rules for logging off inactive project members using the Windows Client Session controls in the Project Properties page. Project administrators may define the amount of time that a project member is idle before that user is automatically logged off the project. The minimum setting is 15 minutes. Page 36 of 145 To enable and define ServiceWise Windows client session log off settings, select the Automatically Log Out User check box and define the idle time Defining List View Refresh Options Project administrators may define how the List window is refreshed in the ServiceWise Windows client using controls in the List View Refresh Option page. Project administrators may choose between three options;

37 Team members can use own time format preference 6To enable employees to define their personal time and date format preferences, select the Employees Can Use Own Time Format Preference check box. 7Click the OK button Managing ServiceWise Windows Client Sessions Project administrators may define rules for logging off inactive project members using the Windows Client Session controls in the Project Properties page. Project administrators may define the amount of time that a project member is idle before that user is automatically logged off the project. The minimum setting is 15 minutes. To enable and define ServiceWise Windows client session log off settings, select the Automatically Log Out User check box and define the idle time Defining List View Refresh Options Project administrators may define how the List window is refreshed in the ServiceWise Windows client using controls in the List View Refresh Option page. Project administrators may choose between three options; Always auto refresh Always manual refresh Based on user preference Project administrators may also define list view refresh options for project Web clients in the List View Refresh Option page Defining Employee Quick Search Settings Project administrators may define quick searches of employees using controls in the List View Refresh Option page. Employee Quick Search enables project members to locate employees based on six employee properties: ID {Employee ID} Employee Name SLA plan ID (s=) Asset No. (a=) Employee phone (p=) Contact (e=) To enable quick searches, select the Enable Employee Quick Search radio button in the Employee Quick Search Option area of the List View Refresh Option page Defining Incident Quick Search Settings Project administrators may enable project members to launch quick searches for incidents using controls in the client tool bar. Incident Quick Search enables project members to locate incidents based on four incident properties: Incident ID (default) Incident name SLA plan ID (s=) Asset No. (a=) To enable quick searches, select the Enable Incident Quick Search radio button in the incident Quick Search Option area of the List View Refresh Option page. 5.3 Managing Optional Project Features Project administrators must enable optional features in the Optional Features page of the General Project Settings folder. Optional features must be enabled before project administrators may configure those features in their ServiceWise projects. Many optional features are only available in the ServiceWise Enterprise Edition. Many optional features require the purchase of separate modules, licenses, or consulting services Optional features are enabled separately in base, marketing, sales, and support projects. Advanced Integration Advanced Event Workflow Advanced Time Tracking and Professional Service Management Auto Escalation Incident routing (autorouting) DownloadPlus integration Employee-specific Web announcements Enable Quick Links FormWise Standard Forms Incident Priority Management TechExcel Search Engine Power User Read-only access to other employee s incidents Subproject support Support KnowledgeWise External Knowledge Enabling or Disabling Optional Features Administrators may use tools in the Optional Features page of the General Project Settings folder to enable or disable optional features in ServiceWise projects. Enabling a feature displays the system page that is required to configure the feature in the Admin Tree window of ServiceWise Admin. The project administrator may configure the feature and it may be used in the project. Disabling a feature hides the system page that is required to configure the feature in the Admin Tree window of ServiceWise Admin. The project administrator may not configure the feature and it cannot be used in the project. Note:TechExcel recommends that optional features that are not in use be disabled so that project settings or workflow rules are not inadvertently defined or overwritten. To enable optional features: 1Select an optional feature. 2Click the Edit button. The Optional Feature dialog box appears. 3Select the check box. 4Click the OK button. The Optional Feature dialog box closes. 5Click the Refresh Tree button. The page needed to configure the optional feature is displayed in the Admin Tree window Understanding Optional Features Many optional features are only available in the ServiceWise Enterprise Edition. Many optional features require the purchase of separate modules, licenses, or consulting services. Some optional features may only be defined in a base project. Certain folders and pages may be added or removed to the ServiceWise client GUI based on administrator-defined configurations. Advanced Integration Advanced Event Workflow Advanced Time Tracking and Professional Service Management Auto Escalation Auto Routing Employee-specific Web Announcement DownloadPlus Integration Enable Quick Web Links Incident Priority Management FormWise Standard Forms TechExcel Search Engine Subproject Support Support KnowledgeWise External Knowledge 5.4 Managing Project Administrators Page 37 of 145 The Project Administrator page enables administrators to identify the user accounts that may administer the TechExcel ServiceWise project. Each project can have multiple administrators. Only active project and system administrators can modify the project settings. Project administrator management tasks include: Adding and Removing Project Administrators

38 DownloadPlus Integration Enable Quick Web Links Incident Priority Management FormWise Standard Forms TechExcel Search Engine Subproject Support Support KnowledgeWise External Knowledge 5.4 Managing Project Administrators The Project Administrator page enables administrators to identify the user accounts that may administer the TechExcel ServiceWise project. Each project can have multiple administrators. Only active project and system administrators can modify the project settings. Project administrator management tasks include: Adding and Removing Project Administrators Adding and Removing Project Administrators Project administrators may add other project members as project administrators within ServiceWise projects using tools in the Project Administrator page of the General Project Settings folder. To add a project administrator to the current project, select the project member in the Available Project Administrators list and click the Add button. To remove a project administrator from the current project, select the project member in the Project Administrators for Current Project list and click the Remove button. Click the Support Member Manager button to open the Support Member Manager. Project administrators may assign project administrator account types to project members in the Project Administrators page. 5.5 Managing Account Types Anaccount typedefines the role of a user account the privileges and responsibilities granted to that user in a ServiceWise work project. TechExcel ServiceWise uses a account types to coordinate project members in project workflow and to implement security in ServiceWise projects. In ServiceWise, all project-level access controls are assigned to account types and not to individual user accounts. Project members inherits privileges from the account type they are assigned in a project. A user may belong to many different projects and be assigned different account types in different work projects. Project administrators are responsible for creating the account types used in each work project, defining the privileges granted to each account type, and assigning account types to each project members based on the role and responsibilities that user performs in the project. Virtually every major function and every field can have its privileges uniquely defined for each account type providing the flexibility to customize the workflow and security to each company unique requirements and procedures. Account type management tasks include: Understanding Account Types Understanding Light Account Types Creating Account Types Editing Account Types Understanding Light Account Types Deleting Account Types Understanding Account Types Project administrators are responsible for creating all of the account types that are used in their project, defining the privileges associated with those account types, and assigning these account types to each project members based on the role and responsibilities that user performs in the project. The account type that is assigned to a user determines the role that the user may play within the project. All privileges and responsibilities assigned to a user within a project are based on their account type. Account types represent specific roles and responsibilities in ServiceWise projects Account types determine the privileges that may be granted to individual project members Account types determine which project members may own or manage incidents during project workflow Account types provide security within the project Account types and privileges TechExcel ServiceWise supports two types of account types: regular account types and light account types. Regular account types are for TechExcel ServiceWise project members that are assigned with single or suite licenses. Light account types are for project members that are assigned a light license and have a limited role in the project Account types and workflow Account types are foundation of workflow in ServiceWise projects. Incidents are assigned to project members based on their account type. The ability of individual project members to own or manage incident in a particular progress state is also based on their account type Account types and project security Account types are the foundation of all security in ServiceWise projects. An account type represents a set privileges that enable users to perform tasks in the ServiceWise client. The ability of a ServiceWise user account to access projects, views, folders, and pages depend on the account type that they are assigned in a project. When a user account is assigned an account type that user inherits all of the privileges and responsibilities that are assigned to that account type. Every user account added to a project by a project administrator must be assigned an account type. Because each ServiceWise user may belong multiple projects, a user can be assigned a different account type for each project based on the role that the user plays in each project Understanding Light Account Types Light account types may be assigned to project members who have a limited role in a project such as an assistant assigned to enter incidents into a support project but does not work on the incidents. A light account type has fewer privileges than a regular account type. A user with a light license (and therefore assigned to a light account type) cannot own incidents: The following privileges are not available for a light account type: Assign incidents within own group Assign incidents to members of all groups Close incidents Reopen incidents Import and delete Define public query Perform inter-project copy Edit linked incidents from other projects Project member assigned a light account type cannot perform any of the knowledge-related operations. A light user may only view public knowledge items, search for knowledge, and link knowledge items to an incident for incident resolution Creating Account Types Project administrators may use controls in the Account Type page of the General Project Settings folder to create all of the account types that may be assigned to users in a ServiceWise project. To create an account type: 1Click the New button in the Account Type page. The New Account Type dialog box appears. 2Select the type of account to be assigned to the account type. TechExcel ServiceWise supports two types of account types: regular account types and light account types. Regular account types are for TechExcel ServiceWise project members that are assigned with single or suite licenses. Light account types are for project members that are assigned a light license and have a limited role in the project. 3Enter a name in the Name field. 4Click the OK button. Note:Project administrators cannot add user accounts to a project until they have created account types. Each user must be assigned an account type before Page 38 of 145 being added to a project Editing Account Types Project administrators may use the Edit button in the Account Type page to rename project account types. Project administrators may not change the type of the account type. Once an account type is defined as a regular account type or a light account type, that

39 1Click the New button in the Account Type page. The New Account Type dialog box appears. 2Select the type of account to be assigned to the account type. TechExcel ServiceWise supports two types of account types: regular account types and light account types. Regular account types are for TechExcel ServiceWise project members that are assigned with single or suite licenses. Light account types are for project members that are assigned a light license and have a limited role in the project. 3Enter a name in the Name field. 4Click the OK button. Note:Project administrators cannot add user accounts to a project until they have created account types. Each user must be assigned an account type before being added to a project Editing Account Types Project administrators may use the Edit button in the Account Type page to rename project account types. Project administrators may not change the type of the account type. Once an account type is defined as a regular account type or a light account type, that account remains that type of account. To edit an account type: 1Select an account type in the Account Type list in the Account Type page. 2Click the Edit button. The Edit Account Type dialog box appears. 3Enter a name in the Name field. 4Click the OK button Deleting Account Types Project administrators may use the Delete button in the Account Type page to delete project account types. To rename an account type: 1Select an account type in the Account Type list in the Account Type page. 2Click the Delete button. The Delete Account Type warning appears. 3Click the OK button. 5.6 Managing Account Access Controls Chapter 6 Incident Administration 6 Chapter 6 -- Incident Administration This chapter describes incident management processes and describes how project administrators may define support incidents and customize a graphical user interface that enables the support organization to effectively manage those incidents including pages and controls. In this chapter: Understanding Support Incident Administration Configuring General Support Incident Properties Administering System Controls Administering Custom Controls Administering Controls Administering System Pages Administering Custom Pages Administering Function Pages 6.1 Understanding Support Incident Administration In ServiceWise, all customer incidents are managed and tracked assupport incidentsin the incident view of the ServiceWise client. A support incident represents a task or set of tasks that may be managed by the support organization in workflow throughout the life cycle of that incident. In ServiceWise, support incidents are managed and tracked in the incident view of the ServiceWise Windows and web clients. Project administrators are responsible for defining the data that is tracked in a work project and for customizing the graphical user interface that support engineers use to manage and track incident data. Every incident is represented by a unique incident ID, a description of the incident, an incident workflow state, a work description, and other dynamic properties. Most incident properties are fully customizable. The data that comprises and incident may vary from project to project. Project administrators may define which properties comprise an incident on a project-byproject basis Understanding Support Incidents Incident administration is essentially the task of identifying the data that needs to be tracked in a project and customizing tools that enable support engineers to collect, manage, and track that data. Define the data collected and tracked in each project by customizing system controls and creating and defining custom controls. Incident administration tasks fall into a number of broad categories. Customize function pages to display system pages and custom pages. Define user access to pages and controls in the ServiceWise client applications. Define relationships between data managed in pages and data-entry controls. Create employee pages and custom controls Understanding Incident View GUI Customization The ServiceWise client is fundamentally a tool for creating, managing, and tracking incidents and the employees, events, and assets that are related to those incidents. The ServiceWise client GUI provides support teams with a tool for viewing and updating all information about the incident. Project members may update incident details, add notes and note attachments, view incident history, or create links between related incidents Project administrators may customize almost every page and data-entry control displayed in the ServiceWise client to support and manage their business processes. Figure 6-1: The ServiceWise Windows Client Page 39 of 145 The incident view of the ServiceWise client consists of two primary panels: theincident list paneland theincident detail panel. Each panel contains tools that enable project members to manage and track incident data. The incident list panel displays high-level information about multiple incidents simultaneously. Each row represents a specific incident. Each column represents an incident property such as its title, incident ID, current owner, and incident workflow state.

40 Figure 6-1: The ServiceWise Windows Client The incident view of the ServiceWise client consists of two primary panels: theincident list paneland theincident detail panel. Each panel contains tools that enable project members to manage and track incident data. The incident list panel displays high-level information about multiple incidents simultaneously. Each row represents a specific incident. Each column represents an incident property such as its title, incident ID, current owner, and incident workflow state. The incident detail panel displays detailed information about a single incident in multiple tabbed form pages the Description page, Current Status page, Events tab, Assets tab, and so on. Each page displays data entry controls that enable project members to define and track incident properties. Project administrators may choose which pages are displayed in the incident detail panel and which data-entry controls are displayed in each page. They may define any number of custom pages and add any number of custom controls to each page Understanding System Controls and Custom Controls In ServiceWise, all incident data is stored, tracked, and managed in two categories of controls: system controls and custom controls. System fields are predefined fields that represent core object properties. System fields are represented in the client by controls that are specifically designed to manage incident data. Many system fields are linked to other fields or to other ServiceWise features, and are not fully customizable. Project administrators may customize the title of each system control. Custom fields are custom defined by the project administrator in each project and are managed in the client using administrator-defined controls. Custom controls are fully customizable. 6.2 Configuring General Support Incident Properties Project administrators may use controls in the General Settings page to define general incident settings in work projects. General incident view customization tasks include: Renaming Support Incidents Defining the Status Control as Read-only Enabling Co-owner Events Configuring Employee Access to Support Incidents Displaying Work Description in Forward Incident Manager Customizing the Incident List Panel Renaming Support Incidents In ServiceWise, all customer support incidents are managed and tracked assupport incidents. The termincidentis used throughout the ServiceWise Admin, Windows, and Web clients. ServiceWise enables project administrators to customize the name that is used to refer to support incidents in each work project. Support organizations may choose to call incidents,tickets,items, or any other term that is familiar to their support team. The Refer Incident As control enables administrators to change the Incident label used in TechExcel ServiceWise. The text entered in this edit box is displayed in instead of the wordincidentthroughout the TechExcel ServiceWise Windows and Web client Defining the Status Control as Read-only In the ServiceWise client, the Status control in the Current Status page enables project members to manage and track the incident workflow states of a support incident. ServiceWise enables project administrators to designate the Status control as read-only in each work project. To designate the Status control as read-only select the Set the Status Field as Read Only in the Current Status Page check box in the General Setting page Enabling Co-owner Events Co-owner events enable support teams to define multiple owners for a single ServiceWise incident. Generally, incident workflow rules mandate that only one project member may own an incident at any one time during the incident life cycle. Using a co-owner events, support teams may temporarily assign incident ownership to multiple project members in a single incident workflow state. To enable co-owner events in a work project, select the Support Co-owner Events check box in the General Setting page. Once co-owner events are enabled, administrators may define co-owner event settings in the Event Management folder Configuring Employee Access to Support Incidents In ServiceWise, employees belonging to the appropriate employee type may view or even edit support incidents in the Employee Web Portal. Employee access to support incidents may be restricted on a state-by-state basis or on an incident-by-incident basis. Project administrators may define how employees access to support incidents are defined in each support project using controls in the in the General Setting page. Employee access may be restricted by one of three methods: The Based on the Incident State Definition Only option: If the Based on Incident State Only option is selected, project administrators may define employee access rules on a state-bystate basis. The Based on the Incident State and Allow per Incident Simplified Access Control option:if the Based on Incident State with per Incident Simplified Access option is selected, project administrators may define employee access rules on a state-bystate basis and enable simplified access on an incident-by-incident basis. The Based on the Incident State and Allow per Incident Full Access Control option:if the Based on Incident State with per Incident Simplified Access option is selected, project administrators may define employee access rules on a state-bystate basis and enable full access on an incident-by-incident basis. 6.3 Administering Controls Acontrolis a GUI element displayed in a window, panel, or dialog box that enables users to define, update, and track data. In ServiceWise, controls enable project member to manage project data including incident, employee, event, and asset properties. Controls displayed in the incident view enable project members to define and manage support incidents. Every incident control is defined by its control category and its control type. The control category defines the relationship between that control and system-defined ServiceWise functionality. ServiceWise supports two categories of controls: system controls and custom controls. The control type defines how the data tracked in the control is managed by the user. ServiceWise supports two categories of controls: system controls and custom controls. Control customization tasks include: Administering System Controls Administering Custom Controls Understanding Control Types Understanding Control Customization Options Defining Control Labels Customizing Autogrow Combo Box Controls Customizing Combo Box Controls Customizing Dropdown List Controls Ordering Options in Selection List Controls Customizing Multiple Selection Controls Customizing Data Grid Controls Administering System Controls ServiceWise is a tool for collecting, managing, and tracking incident, asset, and employee data. All data is managed and tracked in the ServiceWise client using data-entry controls. System fields are predefined fields that represent core object properties. System fields are represented in the client by controls that are specifically designed to manage incident data. Many system fields are linked to other fields or to other ServiceWise features, and are not fully customizable. System fields are predefined data-entry controls that are designed to collect and track specific kinds of incident data. Many system controls incorporate Page 40 of 145 ServiceWise business logic and are required to manage tools. Many system fields are linked to other fields or to other ServiceWise features, and are therefore not fully customizable. Project administrators may change the title of system controls and, in some instances, restrict access to those controls. Every system field consists of four properties: Field ID

41 Customizing Multiple Selection Controls Customizing Data Grid Controls Administering System Controls ServiceWise is a tool for collecting, managing, and tracking incident, asset, and employee data. All data is managed and tracked in the ServiceWise client using data-entry controls. System fields are predefined fields that represent core object properties. System fields are represented in the client by controls that are specifically designed to manage incident data. Many system fields are linked to other fields or to other ServiceWise features, and are not fully customizable. System fields are predefined data-entry controls that are designed to collect and track specific kinds of incident data. Many system controls incorporate ServiceWise business logic and are required to manage tools. Many system fields are linked to other fields or to other ServiceWise features, and are therefore not fully customizable. Project administrators may change the title of system controls and, in some instances, restrict access to those controls. Every system field consists of four properties: Field ID Field name Control title Control type The field ID and field name of system fields are fixed in ServiceWise and cannot be changed. These properties enable administrators to identify fields across projects and facilitate integration and interproject configurations. The control title and the control type of system controls may be customized in ServiceWise projects. But system field customizations are relatively limited when compared to the customizations that may be made to custom controls. The following system controls may be displayed in ServiceWise system or customer pages. Table 6-1: ServiceWise System Field Controls Administering Custom Controls Custom fields are administrator-defined data-entry controls that may be used to collect and track incident data. Project administrators may enable and customize up to 220 custom data-entry controls using the five custom field database pages that may be displayed in the Field Design subfolder of the Incident View folder. Data collected in custom fields may be imported or exported, searched, and used to run reports. The number of custom data-entry controls that an administrator may define and customize in a ServiceWise project depends on the number of custom field database pages that the administrator has enabled in the Field Design Settings page. Pagein The first step towards enabling custom controls in a ServiceWise project is to select the number of custom field database pages that are displayed theof Field Design subfolder. Project administrators may create custom controls based on six different control types:

42 6.3.2 Administering Custom Controls Custom fields are administrator-defined data-entry controls that may be used to collect and track incident data. Project administrators may enable and customize up to 220 custom data-entry controls using the five custom field database pages that may be displayed in the Field Design subfolder of the Incident View folder. Data collected in custom fields may be imported or exported, searched, and used to run reports. The number of custom data-entry controls that an administrator may define and customize in a ServiceWise project depends on the number of custom field database pages that the administrator has enabled in the Field Design Settings page. The first step towards enabling custom controls in a ServiceWise project is to select the number of custom field database pages that are displayed in the Field Design subfolder. Project administrators may create custom controls based on six different control types: Table 6-2: Custom Control Types Project administrators may enable up to five custom field database pages in each project. Each custom field database page enables administrators to define up to 44 different custom controls. To enable custom field database pages: 1Click the Change button in the Field Design Settings page of the Field Design subfolder within the Incident folder. The Increase Total DB Pages for Custom Data dialog box appears. 2Select an option from the dropdown list. Project administrators may enable up to five custom field database pages in each ServiceWise project. 3Click the OK button. All custom fields on these pages can be made mandatory on submission, except for check boxes. Simply select the Mandatory on submission option in the Field attributes section. Each custom field database page displays 44 custom controls that may be defined using six different control types: Table 6-3: Custom Control Types Understanding Control Types All controls are defined by their control type. A control type represents a class of GUI elements that share the same functionality. The control type defines how the data tracked in the control is managed by the user. ServiceWise supports eight different control types: combo boxes, data grids, date-time controls, dropdown lists, edit boxes, multiple selection controls, and multiple line edit boxes. Page 42 of 145

43 Table 6-3: Custom Control Types Understanding Control Types All controls are defined by their control type. A control type represents a class of GUI elements that share the same functionality. The control type defines how the data tracked in the control is managed by the user. ServiceWise supports eight different control types: combo boxes, data grids, date-time controls, dropdown lists, edit boxes, multiple selection controls, and multiple line edit boxes Understanding Control Customization Options In ServiceWise, project administrators may define and customize the controls displayed in each page of the incident detail panel of the ServiceWise client. The control type defines how the data tracked in the control is managed by the user. Selection controls represented by the autogrow combo box, combo box, dropdown list, and multiple selection control types enable users to select an option from an administrator-defined list of options. Page 43 of 145 Input controls represented by the single-line text box, multiple-line text box enable users to input a value. Combination controls the autogrow combo box and the combo box enable users to choose between selecting a predefined option or entering a value. Control customizations include the definition of control field labels, field access rules, and selectable options.

44 6.3.4 Understanding Control Customization Options In ServiceWise, project administrators may define and customize the controls displayed in each page of the incident detail panel of the ServiceWise client. The control type defines how the data tracked in the control is managed by the user. Selection controls represented by the autogrow combo box, combo box, dropdown list, and multiple selection control types enable users to select an option from an administrator-defined list of options. Input controls represented by the single-line text box, multiple-line text box enable users to input a value. Combination controls the autogrow combo box and the combo box enable users to choose between selecting a predefined option or entering a value. Control customizations include the definition of control field labels, field access rules, and selectable options. Table 6-4: Control Customizations The customizations that may be made to a control depend on two factors: thecontrol categoryand thecontrol type. In ServiceWise, every control belongs to one of two control categories: system controls or custom controls. ServiceWise supports eight different control types: combo boxes, data grids, date-time controls, dropdown lists, edit boxes, multiple selection controls, and multiple line edit boxes. The following customizations may be made to controls based on their control type: Table 6-5: Custom Control Types Defining Control Labels A label is a GUI element that identifies an adjacent control. All controls in the ServiceWise client are accompanied by labels. Project administrators may retitle all system and custom controls Defining the Control Type of Custom Controls To customize the control type of custom controls: Page 44 of 145

45 Table 6-5: Custom Control Types Defining Control Labels A label is a GUI element that identifies an adjacent control. All controls in the ServiceWise client are accompanied by labels. Project administrators may retitle all system and custom controls Defining the Control Type of Custom Controls To customize the control type of custom controls: 1Select a custom control in one of the five Custom Fields DB page that may be displayed in thefield Design subfolder in the Incident View folder. 2Click the Define button. The Edit dialog box appears. 3Select a control type from the Field Type dropdown list and click the OK button. Project administrators may change the control type of 28 custom controls in each Custom Fields DB page. The 8 FieldShortText fields may be defined as either Combo Box controls or Edit Box controls. The 8 FieldLongText fields may be defined as either Combo Box controls or Edit Box controls. The 12 FieldInteger fields may be defined as Check Box, Dropdown List, or Edit Box controls Defining Team Member Access Rules In ServiceWise, incident form pages the Description page, the Current Status page, custom pages, and others and the controls displayed in those pages may be made accessible to company employees through the Employee Web Portal. Team access rules enable project administrators to restrict project member access to the data managed in system and custom controls. Each control is defined by one of four employee access rules: Table 6-6: Team Member Access Rules Defining Employee Access Rules In ServiceWise, incident form pages the Description page, the Current Status page, custom pages, and others and the controls displayed in those pages may be made accessible to company employees through the Employee Web Portal. Employee access rules enable project administrators to restrict employee access to the data managed in system and custom controls. Each control is defined by one of four employee access rules: Table 6-7: Employee Access Rules Defining Options in Selection List Controls Selection list controls autogrow combo boxes, combo boxes, dropdown lists, and multiple selection controls enable users to select an option from a predefined list of options. Using controls in the List Setup dialog box, project administrators may add, edit, or delete the options displayed in selection list controls, define the order of options in those lists, and merge control options Defining Parent-Child Relationships Between Controls In ServiceWise, parent-child relationships may be defined between two selection controls autogrow combo boxes, combo boxes, dropdown lists, and multiple selection controls. In a parent-child relationship, the option selected in the parent selection control determines the options that are available for selection in the child selection control Customizing Autogrow Combo Box Controls Page 45 of 145 An autogrow combo box combines a dropdown list with a text box to enable users to either type a value directly into the control or to select a value from an existing list of options. Every value entered into the text box is added to the dropdown list and displayed to subsequent users.

46 Using controls in the List Setup dialog box, project administrators may add, edit, or delete the options displayed in selection list controls, define the order of options in those lists, and merge control options Defining Parent-Child Relationships Between Controls In ServiceWise, parent-child relationships may be defined between two selection controls autogrow combo boxes, combo boxes, dropdown lists, and multiple selection controls. In a parent-child relationship, the option selected in the parent selection control determines the options that are available for selection in the child selection control Customizing Autogrow Combo Box Controls An autogrow combo box combines a dropdown list with a text box to enable users to either type a value directly into the control or to select a value from an existing list of options. Every value entered into the text box is added to the dropdown list and displayed to subsequent users. Figure 6-2: Autogrow Combo Box Control No system fields may be defined using the autogrow combo box control type. All autogrow combo boxes are custom controls. Customizations include: Title Team Access Employee Access Options Parent-Child To add or remove an option to an autogrow combo box control: 1Select a selection control in the System Fields list of the System Field Design page in the FieldDesign subfolder of the Incident View folder. 2Click the Design button. The ServiceWise dialog box appears. 3Click the Setup button. The List Setup dialog box appears. 4Add or remove field values to the selection control. To add field values to the selection control, select the field value in the Inactive Selection list and click the Left Arrow button. To remove field values from the selection control, select the field value in the Active Selection list and click the Right Arrow button. 5Click the OK button. The List Setup dialog box closes. 6Click the OK button. The ServiceWise dialog box closes Customizing Combo Box Controls A combo box combines a dropdown list with a single-line text box to enable users to choose between inputting a value directly into the control or to select a value from an existing list of options. Figure 6-3: Combo Box Control Customizations include: Title Team Access Employee Access Options Parent-Child To add or remove options to selection controls: 1Select a selection control in the System Fields list of the System Field Design page in the Field Design subfolder of the Incident View folder. 2Click the Design button. The ServiceWise dialog box appears. 3Click the Setup button. The List Setup dialog box appears. 4Add or remove field values to the selection control. To add field values to the selection control, select the field value in the Inactive Selection list and click the Left Arrow button. To remove field values from the selection control, select the field value in the Active Selection list and click the Right Arrow button. 5Click the OK button. The List Setup dialog box closes. 6Click the OK button. The ServiceWise dialog box closes Customizing Dropdown List Controls A dropdown list enables users to select a value from a list of predefined options. Figure 6-4: Dropdown List Control Other features of selection controls include the definition of parent-child relationships between selection controls. Customizations include: Title Team Access Employee Access Options Parent-Child To add or remove options to selection controls: 1Select a selection control in the System Fields list of the System Field Design page in the Field Design subfolder of the Incident View folder. 2Click the Design button. The ServiceWise dialog box appears. 3Click the Setup button. The List Setup dialog box appears. 4Add or remove field values to the selection control. To add field values to the selection control, select the field value in the Inactive Selection list and click the Left Arrow button. To remove field values from the selection control, select the field value in the Active Selection list and click the Right Arrow button. 5Click the OK button. The List Setup dialog box closes. Page 46 of 145

47 Employee Access Options Parent-Child To add or remove options to selection controls: 1Select a selection control in the System Fields list of the System Field Design page in the Field Design subfolder of the Incident View folder. 2Click the Design button. The ServiceWise dialog box appears. 3Click the Setup button. The List Setup dialog box appears. 4Add or remove field values to the selection control. To add field values to the selection control, select the field value in the Inactive Selection list and click the Left Arrow button. To remove field values from the selection control, select the field value in the Active Selection list and click the Right Arrow button. 5Click the OK button. The List Setup dialog box closes. 6Click the OK button. The ServiceWise dialog box closes Ordering Options in Selection List Controls ServiceWise enables support organizations to manage and track incident, employee, and asset data in three types of selection controls: autogrow combo boxes, combo boxes, and dropdown lists. Selection list controls present users with a predefined list of options from which the user may choose a single value. By default, the options in the list are displayed in alphabetical order. Project administrators may define the order of options in the list. To order options in a selection control: 1Select a selection control in the System Fields list of the System Field Design page in the Field Design subfolder of the Incident View folder. 2Click the Design button. The ServiceWise dialog box appears. 3Click the Setup button. The List Setup dialog box appears. 4Move field values up or down in the selection control: To move field values up in the selection control list, select the field value in the Active Selection list and click the Up Arrow button. To remove field values down in the selection control list, select the field value in the Active Selection list and click the Down Arrow button. 5Click the OK button. The List Setup dialog box closes. 6Click the OK button. The ServiceWise dialog box closes Customizing Multiple Selection Controls A multiple selection control is GUI element control type that enables users to select multiple values from a predefined list of options. Figure 6-5: Multiple Selection Control In ServiceWise, all multiple selection controls are custom controls that have been created and defined by a project administrator. Custom controls may be added to system pages and custom pages that are displayed in the ServiceWise client. Project administrators may create and name multiple selection controls in the Multiple Selection Control page in the Field Design subfolder of the Incident View folder. The following customizations may be made to multiple selection controls: Customizations include: Title Team Access Employee Access Options Parent-Child To create a multiple selection control: 1Click the Add button in the Multiple Selection Control page in the Field Design subfolder of the Incident View folder. The Add Multiple Selection Control dialog box appears. 2Input the title of the control in the Display Name text box. 3Click the OK button. The Add Multiple Selection Control dialog box closes. The multiple selection control is displayed in the Multiple Selection Control list. To customize multiple selection controls: 1Add to a system page or custom page. 2Select the Setup button. 3XREF 4XREF Customizing Data Grid Controls A data grid is GUI element control type that presents data in a tabular list of rows and columns A project administrator may create one data grid control in each project and display that control in the Description page. Figure 6-6: Data Grid Control The data grid is visually comparable to a worksheet in a spreadsheet application consisting of multiple columns and rows. Every column in the data grid bears an administrator-defined title. The rows may optionally be titled as well. Project administrators may define the control type and data type of each column in the data grid. ServiceWise supports five options: Edit box (text):a single-line text box enables users to input a single line of text. Edit box (int):an integer text box enables users to input a single line of text. Edit box (float):a float text box enables users to input a single line of text. Dropdown list:a dropdown list enables users to select a value from a list of predefined options. Date-time field:a date-time control enables users to select a specific date in a popup calendar. Project administrators may make the following customizations to the data grid control: Customize the title of the data grid control. Add columns to the data grid control. Add rows to the data grid control. Define column header titles. Page 47 Define team access rules: the data grid control may be defined as Visible and Editable, Not visible, Visible and Read-only, Read-only but Editable at Submit. Define employee access rules Customizing Single-line Text Box Controls of 145

48 Edit box (int):an integer text box enables users to input a single line of text. Edit box (float):a float text box enables users to input a single line of text. Dropdown list:a dropdown list enables users to select a value from a list of predefined options. Date-time field:a date-time control enables users to select a specific date in a popup calendar. Project administrators may make the following customizations to the data grid control: Customize the title of the data grid control. Add columns to the data grid control. Add rows to the data grid control. Define column header titles. Define team access rules: the data grid control may be defined as Visible and Editable, Not visible, Visible and Read-only, Read-only but Editable at Submit. Define employee access rules Customizing Single-line Text Box Controls A single-line text box enables users to input a single line of text. Customizations include: Title Team Access Employee Access Customizing Multiple-line Text Box Controls A multiple-line text box enables users to input multiple lines of text. Multiple-line text box controls, also calledmemo fields, are data-entry controls that enable support organizations to conduct extended discussions about incidents, events, employees and other business objects tracked in work projects. Common multiple-line text box controls include: Description Close Note History Incident Notes Link Comments Event Description All custom-defined multiple-line text controls Text managed in multiple-line text box controls is searchable using the TechExcel Search Engine. For more information see See Administering the TechExcel Search Engine on page 79. Customizations include: Title Team Access Employee Access Time stamping may be enabled for three multiple-line text box system controls: the Description control, the Work Description control, and the Notes control Enabling Multiple-line Text Box Time Stamping A time stamp is a signature that is concatenated to text entered in the data-entry field. ServiceWise time stamps log the exact date and time of the entry, the name of the project member entering the data, and the action that accompanied the work description entry. The Description control, Work Description control, and Note control support the time stamping of all data entered into the control. In addition, project administrators may define time stamped entries as indelible: once entered the entries cannot be edited or deleted. Subsequent entries may be made, but these entries are marked by a unique time stamp. To enable a multiple-line text box time stamping: 1Select a system page or custom page. 2Click the Setup button. The GUI Layout Setup dialog box appears. 3Select the multiple-line text box control in the control list. Time stamping may be enabled for the Description control, the Work Description control, and the Note control. 4Click the Design button. The ServiceWise dialog box appears. 5Select the Description with Time Stamp button. 6Click the OK button. The ServiceWise dialog box closes. Time stamping is an optional feature that must be enabled by a project administrator in each DevTrack project Customizing Check Box Controls A check box enables the user to choose between two mutually exclusive options: selected (true) or clear (false). Customizations include: Title Team Access Employee Access Customizing Date-Time Controls A date-time control enables users to select a specific date in a popup calendar. In its inactive state the control looks like a text box with a small button (the ellipsis button). Clicking the ellipsis button displays the popup calendar that enables the user to browse and select the date. Customizations include: Title Team Access Employee Access Defining Team Member Access Rules To define team member access rules: 1Select a system page or custom page. 2Click the Setup button. The GUI Layout Setup dialog box appears Defining Employee Access Rules To define employee access rules: 1Select a system page or custom page. 2Click the Setup button. The GUI Layout Setup dialog box appears. To field dimensions: 1Select a system page or custom page. 2Click the Setup button. The GUI Layout Setup dialog box appears. 3Select the multiple-line text box control in the control list. 4Click the Design button. The ServiceWise dialog box appears. 5Select an option from the Width dropdown list control. 6Select an option from the Height dropdown list control. 7Click the OK button. 8The ServiceWise dialog box closes. 6.4 Administering System Pages Page and 48 track of 145 A system page is a system-defined form page that may be displayed in the ServiceWise clients which enables project members to collect, manage, incident data. System pages are displayed in the ServiceWise clients as tabbed pages in the incident detail panel and the incident manager dialog boxes. ServiceWise supports four core system pages: The Description system page The Current Status system page

49 6.4 Administering System Pages A system page is a system-defined form page that may be displayed in the ServiceWise clients which enables project members to collect, manage, and track incident data. System pages are displayed in the ServiceWise clients as tabbed pages in the incident detail panel and the incident manager dialog boxes. ServiceWise supports four core system pages: The Description system page The Current Status system page The History system page The Events system page Project administrators may choose which system pages are displayed in the incident detail panel and incident managers, customize the incident list, and add or remove system or custom controls to system pages in the System Pages subfolder of the GUI Design folder. System pages feature the built-in funcitonality of system controls. Unlike custom controls which are fully customizable and may be used to track any type of data, each system control is specifically designed to track a particular set of data and in linked to other controls and functionalities in ServiceWise. System page administrative tasks include: Customizing the Incident Detail Panel Adding the Link Page to the Incident Detail Panel Customizing the Description System Page Customizing the Current Status Page Customizing the History Page Customizing the Incident Detail Panel In the ServiceWise client, the incident detail panel displays detailed information about a single incident in multiple tabbed form pages the Description page, Current Status page, History page, Events page, Assets page, and so on. Each page displays data entry controls that enable project members to define and track incident properties. Project administrators may define the display order system pages and custom pages in the incident detail panel Adding the Link Page to the Incident Detail Panel To enable the Link system page and display that page in the incident detail panel, select the Show Link Page check box in the Incident Detail Page page of the System Pages subfolder in the GUI Design folder Customizing the New Incident Manager In the ServiceWise client, project members may define new support incidents in the New Incident manager. The New Incident Managers is a multiple tabbed dialog box that is displayed on the user s desktop whenever a project member submits a new incident. By default, the New Incident manager displays a single form page the incident detail system page. Project administrators may customize the New Incident manager to display additional pages: Current Status system page Event Selection system page Up to five custom pages Managing the Incident List Window Indicators Administrators may use controls in the Incident Detail Page system page to determine which pages are displayed in the Incident Submission manager and Incident Detail window of the TechExcel ServiceWise clients. Figure 6-7: Dialog Customizing the Description System Page In the ServiceWise client, the Description page is the primary page for defining and tracking core incident properties. The Description page is displayed in the incident detail panel and in the incident manager dialog boxes including the New Incident manager, the Forward Incident manager, and the Close Incident manager. The Description page tracks general information about an incident. All of the fields on the Description page, including the page title, can be customized in some fashion. Administrators may customize many of the system controls displayed in the Description page. The customizations made are different for each data-entry control. Administrator may also add up to three custom controls to the Description page. Custom controls are... Key incident properties tracked in the Description page include the incident title and description as well as other properties that identify the incident. Project administrators may use controls in the Description system page to add and remove system, custom, and multiple-selection controls to the Description page, customize the layout of controls in the page, and define the tab order. All controls are selected, added, and ordered using controls in the GUI Layout Setup manager Customizing the Current Status Page In the ServiceWise client, the Description page is the primary page for defining and tracking core incident properties. The Description page is displayed in the incident detail panel and in the incident manager dialog boxes including the New Incident manager, the Forward Incident manager, and the Close Incident manager. Key incident properties tracked in the Description page include the incident title and description as well as other properties that identify the incident. Project administrators may add or remove system controls, custom controls, and multiple-selection controls to the Current Status page using controls in the Current Status system page. All of the fields on the Current Status page, including the page title, may be customized in some fashion. Page 49 of 145

50 The Progress Status control, Assigned By control, Substatus control, and Work Description control are all mandatory in the Current Status page. Project administrators may not remove these controls from the page Customizing the History Page In the ServiceWise client, the History page provides project members with a read-only audit log of all changes. The only control that may be customized in the History page is the page title field label. 6.5 Administering Custom Pages Project administrators may enable and customize up to five custom pages in a ServiceWise project. Custom pages enable businesses to create form pages that are uniquely designed to collect and track data that is specific to their environment and business. Each custom page may display up to 12 data-entry controls. Project administrators may add system-defined controls, custom-defined controls, and customdefined, multiple-selection controls Adding and Removing Controls to Custom Pages Project administrators may add and remove system, custom, and multiple-selection controls to custom pages, customize the layout of controls in the page, and define their the tab order using the GUI Layout Setup manager. All controls are selected, added, and ordered using controls in the GUI Layout Setup manager. Figure 6-8: GUI Layout Setup Page Specify the field label in the Control Label section. Next, select the control type of the field. The following control types are available: Check Box Edit Box Multi-line Edit Box Dropdown List Combo Box 6.6 Administering Function Pages A function page is a system-defined page that represents a special type of dialog box that is displayed in the ServiceWise client. All incident management tasks are represented by actions submitting actions, updating actions, forwarding actions, closing actions, and reopening actions. Chapter 7 Advanced Incident Administration 7 Chapter 7-- Advanced Incident Administration This chapter describes the configuration of advanced incident management tools including incident linking and incident priority tracking. In this chapter: Administering Incident Linking Managing the Web Conversation Page AdministeringIncidentWorkflowStateDisplay Order Managing Incident Priority Administering the Change Log 7.1 Administering Incident Linking In ServiceWise, incident linking facilitates the management and tracking of related support incidents and enables project administrators to define complex rules to manage related incidents based on their relationships. Incident linking enables support organizations to identify and track related support incidents as single units. Linked incident details may be viewed and updated whenever its link is accessed. Administrator-defined workflow rules may tie the progress of a support incident to the successful completion of other incidents that are linked to it. An incident link creates a relationship between two support incidents and defines rules that define how those incidents are managed in the project. Every incident link is based on an administrator-defined link type. ServiceWise incident linking administrative tasks include: Understanding Incident Linking Defining Referential Link Types Defining Parent-Child Link Types Understanding Incident Linking ServiceWise enables support organizations to create two different types of links between incidents: referential links and parent-child links. Referential links define a simple relationship between two incidents and facilitates the management and tracking of these incidents. Parent-child links define a relationship in which the workflow state of one incident may be defined by the progress made on the other incident. An incident link facilitates the tracking and management of related incidents. Linked incidents may be tracked in the ServiceWise client. All incident linksbidirectional: project members may view and track detailed information about either incident by accessing the linked incident in the ServiceWise client. Whenever a project member creates a link between two incidents in the ServiceWise client, the project member must select an administrator-defined link type to define the relationship between those incidents and the rules that manage their relationship. Using interproject linking, administrator-defined link types may also define the relationship between incidents in separate ServiceWise projects, between support incidents in ServiceWise and CustomerWise projects, or between ServiceWise support incidents and DevTrack development issues. Once a link type is defined in the Link Type manager that link type is available for selection in the ServiceWise client whenever a project member creates a link between two incidents Defining Referential Link Types Page 50 of 145

51 Referential links may be used to define simple relationships between two support incidents and to enable support organizations to better identify and track multiple incidents that are related to one another. Every referential link is based on an administrator-defined referential link type. A referential link type is defined by three properties: its link type name, link type category, and link type description. Unlike parent-child link types, referential links do not define workflow enforcement rules for managing the linked incidents. Either incident in a referential link may be updated or closed freely without affecting the incident state of other incident in the relationship. To define a referential link type: 1Access the Link Type manager. All link types may be defined in the Link Type manager in the ServiceWise Admin client. Project administrators may access the Link Type manager from two pages. Click the Define Link Type button in the Incident Link Type page of the Incident View folder. Click the Define Link Type button in the Interproject Copy page in the Advanced Settings folder. The Define Link Types manager opens. 2Click the New button. The Define a Link Type Define dialog box opens. 3Enter a name in the Link Type Name text box. 4Select the Reference Link radio button in the option Link Type Category area. 5Enter a brief description of the link type in the Link Type Description control. 6Click the OK button. The Link Type Define dialog box closes Defining Parent-Child Link Types Parent-child links define dependency relationships between two support incidents and enable support organizations to manage the workflow of related incidents as a single unit. Parent-child links define relationships based on aworkflow enforcement rule. Enforcement rules define how linked incidents when a project member attempts to close a parent or child issue: No Enforcement: Freely Close Parent or Child IncidentThe No enforcement: Freely Close Parent Or Child Incident rule creates a simple referential relationship between the linked incidents. Warning: Do Not Close A Parent Incident Until All the Child Issues Get ClosedThe Warning: Do Not Close a Parent Incident Until all the Child Incidents Are Closed rule creates a warning message that is displayed in the client whenever a project member attempts to close parent incident that is linked to open child incidents. Enforce: Cannot Close A Parent Incident Until All the Child Issues Get ClosedThe Enforce: Cannot Close a Parent Incident Until all the Child Incidents Are Closed rule mandates that a project member close all child incidents before a parent incident can be closed. Warning: Do Not Close Child Incident Until the Parent Issue Is ClosedThe Warning: Do Not Close a Child Incident Until the Parent Incident Is Closed rule creates a warning message that is displayed in the client whenever a project member attempts to close a child incident that is linked to open parent incident. Enforce: Cannot Close Child Incident Until the Parent Issue Is ClosedThe Enforce: Cannot Close a Child Incident Until the Parent Incident Is Closed rule mandates that a project member close the parent incident before the linked child incident can be closed. Auto Close Child Incident When Parent Incident Is ClosedThe Auto Close Child Incident when Parent Incident Is Closed rule automatically closes all child incidents whenever a linked parent incident is closed. Every parent-child link is based on an administrator-defined parent-child link type. A parent-child link type is defined by four properties: its link type name, link type category, link type description, and a workflow enforcement rule. To define parent-child link types: 1Access the Link Type manager. All link types may be defined in the Link Type manager in the ServiceWise Admin client. Project administrators may access the Link Type manager from two pages. Click the Define Link Type button in the Incident Link Type page of the Incident View folder. Click the Define Link Type button in the Interproject Copy page in the Advanced Settings folder. The Define Link Types manager opens. 2Click the New button. The Define a Link Type Define dialog box opens. 3Enter a name in the Link Type Name text box. 4Select the Parent-Child Links radio button in the Link Type Category area 5Define parent-child link close time enforcement rules. The Close Time Enforcement area displays six options: No enforcement: freely close parent or child issue Warning: do not close a parent issue until all the child issues get closed Enforce: cannot close a parent issue until all the child issues get closed Warning: do not close child issue until the parent issue gets closed Enforce: cannot close child issue until the parent issue gets closed Auto close child issues when the parent issue gets closed. 6Enter a brief description of the link type in the Link Type Description page. 7Click the OK button. The Link Type Define dialog box closes. 8Click the Close button in the Link Types manager. 7.2 Managing the Web Conversation Page The web conversation is a useful tool for communicating with employees. The Web Conversation page provides support project members a powerful tool for communicating with employees about their incidents. The Web Conversation page features a rich text chat-like interface, with time stamped and logged data input. Project administrators may use controls in the Web Conversation page to automatically add a new web conversation note whenever an is sent, or when a new event is added from that employee to the incident. Project administrators may enable two options in the Web Conversation page: The Auto Add a New Web Conversation when a Employee Submits a New Event option The Auto Add a New Web Conversation when a Employee Sends a New option Project administrators must enable support for the Web Conversation feature in the Project Properties page. Web conversations are enabled in each project independently. 7.3 Administering Incident Workflow State Display Order Project administrators may customize the display order of progress states in the Progress Status Display Order page. The display order affects the display of incident workflow states in the ServiceWise Windows client. The display order of the progress states in the progress state filter dropdown at the top of every page in the TechExcel ServiceWise Windows and Web client. The display order of the progress states in the progress state dropdown when submitting new incidents or forwarding incidents. The display order for progress states when running reports and grouping by progress state. All progress states as defined in the workflow settings (in the Advanced Project Settings folder) are displayed in the Progress Status pane. 7.4 Managing Incident Priority Project administrators may use controls in the Incident Prioritization page of the Advanced Project Settings folder in ServiceWise Admin to enable support and define settings for priority order management and priority value management in ServiceWise projects. ServiceWise project teams may prioritize incidents using two different methods: Priority order managementenables project members to assign a number (a rank) to each incident. A project member that has ten incidents may rank each incident with a unique priority order number from one to ten. Priority value managementenables administrators to define a formula for assigning a priority value to each incident based on its property definitions. Page 51 of 145

52 Every ServiceWise incident may have both a priority value and priority order number associated with it, giving incident owners tools to determine the most critical incidents in their incident list. Note:The Priority field in the Description page and the incident priority value and incident priority order number are unrelated. The Priority control represents a customizable property of an incident. Prioritization numbers are values assigned to an incident based on the prioritization formula. Project administrators must enable incident prioritization management in the Optional Features page of the General Project Settings folder. The Incident Prioritization page is displayed in the Advanced Project Settings folder only if the project administrator has enabled this feature. Incident priority administrative tasks include: Understanding the Incident Prioritization Page Enabling Incident Prioritization Defining Priority Value Management Granting Incident Prioritization Access Controls Understanding the Incident Prioritization Page Project administrators may use controls in the Incident Prioritization page of the Advanced Project Settings folder in ServiceWise Admin to enable and define incident priority management in ServiceWise projects. Figure 7-1: Incident Prioritization page The Incident Prioritization page consists of three tabbed pages: The General Setting page enables administrators to enable incident prioritization features. The Prioritization Weight page enables administrators to define weights for prioritizing incidents in a project. The Privilege page enables administrators to grant privileges to project members based on their account type Enabling Incident Prioritization Project administrators may use controls in the General Settings tab of the Incident Prioritization page to enable incident prioritization management in ServiceWise projects. Project administrators may enable incident prioritization management for managers and enable prioritization calculations. The Support Prioritization Order Assignment by Managers option enables prioritization order numbers to be displayed to project members in their ServiceWise clients. Every incident is associated prioritization order number which project members may view or edit in the Prioritization list. Incident prioritization order numbers do not change unless manually adjusted by a user with the appropriate privileges. The Support Prioritization Value Calculation option enables prioritization values to be displayed to project members in their ServiceWise clients. Every incident is associated prioritization value which project members may view in the Prioritization list Defining Priority Value Management Project administrators may use controls in the Incident Prioritization page of the Advanced Project Settings folder in ServiceWise Admin to enable and define priority value management in ServiceWise projects. When a project team uses priority value management the priority value of an incident is automatically calculated based on an administrator-defined formula. The formula that calculates the priority value of each incident is based on two primary factors: incident property definitions and time factors Incident property definitions Project administrators may define select which data-entry controls are applicable for determining incident priority values and assign weights to the options displayed in each applicable field Incident time factors Time factor priority values are based on the number of days that an incident remains open and the weight that the administrator assigns to the factor. Project administrators may enable up to three time factors and assign a weight for each time factor. Time factors include the number of days that the incident has been open, the number of days since the incident was last modified, or the number of days the incident is past due. For each time factor the administrator-defined weight is multiplied by the number of days the incident has remained open to arrive at a value. To define priority value management settings: 1Select the Incident Prioritization page in the Advanced Project Settings folder of the Admin Tree window. 2Select the General Setting tab 3Select the Support Priority Value (Severity Number) tab. 4Select options in the Applicable Fields for Priority Value field. Project administrators may define priority weights for the options available in all selected applicable controls. 5Enable one or more time factor option by selecting the appropriate check boxes. 6Define a weight for each selected time factor option. ServiceWise multiples the weight by a number of days to arrive at a time factor. The Days Open option represents the number of days that the incident is open. If an incident was created twenty days previously, the weight is multiplied by twenty to arrive at the time factor. The Days Since Modified option represents the number of days since an incident was last modified. If an incident was modified ten days previously, the weight is multiplied by ten to arrive at the time factor. The Days Past Due option represents the number of days since an incident was last modified. If the deadline for an incident passed three days previously, the weight is multiplied by three to arrive at the time factor 7Select the Priority Weight tab. 8Select an option in the Field list. Only those fields selected in the Applicable Fields for Priority Value list of the General Setting tab are displayed in the Field list. 9Select an option in the Choice list. The Choice list displays all of the options displayed in the selected multiple choice list control. 10Enter a value in the Weight field. The weight value of each choice represents the relative weight assigned to that field choice Granting Incident Prioritization Access Controls Page 52 of 145

53 Project administrators may grant two priority order management privileges to each account type. The Can Edit Own Priority Order privilege The Can Edit All Priority Order privilege Project members may not change the priority value of incidents. Priority order management privileges are granted to project account types. Project members inherit all privileges assigned to their account type. To grant incident prioritization privileges: 1Select the Privilege tab. 2Select an account type in the Account Type list. 3Select privilege options for the selected account type. 7.5 Administering the Change Log In the TechExcel ServiceWise client, project members may view the change log (or audit trail) of each incident in the History page. The change log tracks every field change made to the incident. This information can provide very valuable information about an incidents life cycle. A project administrator can choose not to track change log information by disabling the change log. This is specified on the Change Log page found in the Advanced Project Settings folder. Select the option at the top of the page to enable the change log in the client applications. Note:TechExcel highly recommends that the change log is always enabled as some of the reports rely on change log information for historical changes. In addition, if the change log is enabled project team members will have a much more accurate log of an incident s history. Project administrators may delete old change logs by clicking the Delete old logs button and specifying the latest date for log deletion. Deleting historical changes may affect your report results. There should be no need to ever delete change log information. Chapter 8 Interproject Copying and Linking 8 Chapter 8 -- Interproject Copying and Linking This chapter describesinterprojectincident management tools that provide development organizations with greater power and flexibility to manage business processes across multiple projects. In this chapter: Understanding Interproject Copying and Linking Enabling and Configuring Interproject Copying and Linking Mapping Incident Property Fields 8.1 Understanding Interproject Copying and Linking ServiceWiseinterprojectmanagement enables support organizations to copy incidents from one project to another project, create links between incidents in different projects, and track linked support incident or development issues usinginterprojectactions. Interproject actions andinterprojectlinks provide support organizations with greater flexibility and power to manage support incidents across multiple projects. Interproject Copy:Aninterprojectcopy is a procedure by which a ServiceWise project member may copy a support incident to other ServiceWise projects, CustomerWise or DevTrack projects from a ServiceWise client. Interproject Link:Aninterprojectlink ties incidents in different projects together and enables project teams to view and manage incidents in other projects. Support incidents that are managed and tracked in ServiceWise projects may be linked to development issues managed in TechExcel DevTrack projects or to sales and marketing incidents managed in TechExcel CustomerWise projects. Interproject actions and linking provide support organizations with the following benefits: Interproject incident copying: Project members may copy incidents in a ServiceWise project and submit those incidents to a target project. Interproject linking: Project members may create referential or parent-child links between incidents submitted or copied to a target project and incidents in the originating ServiceWise project. Tracking and editing linked incidents: Interproject links may enable project members to view, edit, and manage the linked incidents in the ServiceWise client Administrating Standard Interproject Actions and Linking Standard interproject action and linking administration is a four step process: Enable target projects: All standard interproject actions and linking is defined on a project-by-project basis. Project administrators must define rules for each project independently. Enable and define standard interproject actions: Standard interproject actions (interproject submission and interproject copying) are defined by default incident owner rules, default account access rules, default incident templates, and concatenated incident titling rules. Standard interproject action rules are defined on a project-by-project basis in the Properties tab of the Interproject Copy page. Define applicable link types for interproject linking: For each enabled target project, project administrators may define one or more applicable link types. Link types define the relationship between linked incidents in different projects. Every link type belongs to one of two link type categories: the referential link type category or the parent-child link type category. Define field mapping and field choice mapping: The mapping of incident property fields between projects, enables project members to submit or copy incidents between heterogeneous projects. Interproject mapping is defined in the Field Map tab of the Interproject Copy page. Interproject field choice mapping is defined in the Field Choice Map tab of the Interproject Copy page. 8.2 Enabling and Configuring Interproject Copying and Linking Interproject actions enable project members to copy the incidents managed in one ServiceWise project and submit copies of those incidents to other ServiceWise, CustomerWise, or DevTrack projects. Interproject links between the original incident and its copy enable project members in either project to track the progress of linked incidents in the other project. To define interproject copying and linking rules, an administrator must first identify applicable target projects, enable interproject copying, enable interproject linking, define applicable link types for target projects, map fields between incidents in different projects. Project-level interproject action and linking settings define the options that are available to project members in the ServiceWise clients. Project members may perform no action, linking, or editing unless that task has been defined applicable by the project administrator. And all actions, linking, and editing rules are defined independently for each target project. Interproject copying is enabled on a project-by-project basis. Project administrators may enable or disable interproject actions for each target project. Interproject linking is enabled on a project-by-project basis. Project administrators may enable or disable interproject linking for each target project. Link types are enabled on a project-by-project basis. Project members may create links between incidents in different projects using any link type that has been defined as applicable to the target project. Interproject linked incident editing rules are enabled or restricted on a project-by-project basis. Interproject administrative tasks include: Enabling Target Projects Enabling Interproject Copying Page 53 of 145

54 Enabling Interproject Linking EnablingWorkflowStateEditing Enabling Incident Owner Editing Defining Default Owners in Target Project Work Description Editing Rules Title and Description Editing Rules Defining Concatenated Incident Title Prefixes Defining Default Account Type Access Rules Defining Default Subprojects Enabling Target Projects A target project is a ServiceWise, CustomerWise, or DevTrack project that has been identified and enabled by the project administrator. Incidents may be copied from the current project to the target project and links may be created between project incidents and incidents or issues in the target project. To enable interproject copying and linking between the current project and another project, select the project in the project list of the Interproject Copying page of the Advanced Project Settings folder. A red check mark is displayed next to the title of the enabled target project. Once a project has been enabled for interproject copying, the administrator may enable and define interproject action settings including interproject copying and interproject linking Enabling Interproject Copying Interproject copying enables project members to duplicate support incidents in the current work project and submit copies of those incidents to other ServiceWise, CustomerWise, or DevTrack projects. To enable interproject copying between the current ServiceWise project and another ServiceWise, CustomerWise, or DevTrack project, select the target project in the project list and select the Enable Interproject Copying check box in the General Setting tab of the Interproject Copying page of the Advanced Project Settings folder Enabling Interproject Linking Interproject linking enables project members to create links between support incidents in the current work project and support incidents or development issues in other ServiceWise, CustomerWise, or DevTrack projects. To enable interproject linking between the current ServiceWise project and another ServiceWise, CustomerWise, or DevTrack project, select the target project in the project list and select the Enable Interproject Copying check box in the General Setting tab of the Interproject Copying page of the Advanced Project Settings folder Enabling Workflow State Editing Interproject workflow state editing rules enable project members to update the incident state of linked support incidents in other projects. To enable the management of incident workflow states between the current ServiceWise project and another ServiceWise, CustomerWise, or DevTrack project, select the target project in the project list and select the Can Edit Progress Status check box in the General Setting tab of the Interproject Copying page of the Advanced Project Settings folder Enabling Incident Owner Editing Interproject incident owner editing rules enable project members to update the ownership status of linked support incidents in other projects. To enable the management of incident owners between the current ServiceWise project and another ServiceWise, CustomerWise, or DevTrack project, select the target project in the project list and select the Can Edit Owner check box in the General Setting tab of the Interproject Copying page of the Advanced Project Settings folder Defining Default Owners in Target Project In ServiceWise, default incident owner rules determine which project member or group folder is defined the default owner of incidents copied to that project using and interproject action. Any user account, or group folder as well the {Auto-assignment}, {Submitter}, {Unassigned} user variables may be defined as the default owner of the incident in the target project. User Account:If a user account is selected, that project member is defined as the default owner of all incidents copied between the two projects. Group Folder:If a group folder is selected, that group folder is defined as the default owner of all incidents copied between the two projects. Auto-Assignment:If the {Auto-Assignment} variable is selected, administrator-defined routing rules determine how the incident is assigned in the target project. For more information on incident routing rules see Administering Incident Routing. Submitter:The {Submitter} user variable identifies the original submitter of an incident as the default owner of incidents defined through interproject actions. Unassigned:The {Unassigned} user variable ensures that incidents submitted or copied by interproject actions remain unassigned to any project member. The selected project member or group folder is the default owner of all incidents submitted or copied to that project by an interproject action. To define the default owners in a target project: 1Select an enabled target project in the project list in the General Setting tab of the Interproject Copying page in the Advanced Features folder. All interproject action rules are defined on a project-by-project basis and only apply to the selected target project. A target project is enabled for interproject actions when a red check mark appears next to the project title. 2Select an option in the Default Folder/Member to be Assigned dropdown list. The Default Folder/Member to be Assigned dropdown list displays the group folders and project members in the target project as well as the {autoassign} variable Work Description Editing Rules Interproject workflow description editing rules enable project members to edit work descriptions of linked support incidents in other projects. To define the default owners in a target project: 1Select an enabled target project in the project list in the General Setting tab of the Interproject Copying page in the Advanced Features folder. All interproject action rules are defined on a project-by-project basis and only apply to the selected target project. A target is enabled for interproject actions when a red check mark appears next to the project title. 2Select an option from the Work Description and Other Properties dropdown list. The Title and Description dropdown list displays three options: Edit with Timestamp Freely edit Read-only Title and Description Editing Rules Interproject workflow description editing rules enable project members to edit the title and description of linked support incidents in other projects. To define the default owners in a target project: 1Select an enabled target project in the project list in the General Setting tab of the Interproject Copying page in the Advanced Features folder. All interproject action rules are defined on a project-by-project basis and only apply to the selected target project. A target is enabled for interproject actions when a red check mark appears next to the project title. 2Select an option from the Title and Description dropdown list. The Title and Description dropdown list displays three options: Edit with Timestamp Freely edit Read-only Defining Concatenated Incident Title Prefixes In ServiceWise, a title prefix is an administrator-defined text string that is automatically concatenated to the title of incidents copied across projects. By default, incidents copied to the target project share the same title as the original incident. Thus, an incident titledcannot login to accounting web clientin the original project would be titledcopied East Coast: Cannot login to accounting web clientin the target project if the title prefix is Copied East Coast:. Concatenated title prefixes enable support organizations to quickly identify, filter, and sort incidents that have been added to their projects using interproject actions. To define concatenated incident title prefixes: 1Select an enabled target project in the project list in the General Setting tab of the Interproject Copying page in the Advanced Features folder. All interproject action rules are defined on a project-by-project basis and only apply to the selected target project. A target is enabled for interproject actions when a red Page 54 of 145

55 check mark appears next to the project title. 2Enter a text string in the Title Prefix Concatenated text box Defining Default Account Type Access Rules In ServiceWise, default account type access rulesdefine which project members may access linked incidents in other projects based on their account type. Default account type access rules enable users of a particular account type to access and manage support incidents in other projects even though they are not members of those projects. To define default account type access rules: 1Select an enabled target project in the project list in the General Setting tab of the Interproject Copying page in the Advanced Features folder. All interproject action rules are defined on a project-by-project basis and only apply to the selected target project. A target is enabled for interproject actions when a red check mark appears next to the project title. 2Select an option from the Default Account Type dropdown list. The default account type enables project members that are not members of the target project to submit, copy, or link incidents between their ServiceWise project and the target project Defining Default Subprojects In ServiceWise, default subproject interproject copying rulesdefine the subproject to which incidents are copied to in the target project using an interproject action. To define default subprojects: 1Select an enabled target project in the project list in the General Setting tab of the Interproject Copying page in the Advanced Features folder. All interproject action rules are defined on a project-by-project basis and only apply to the selected target project. A target is enabled for interproject actions when a red check mark appears next to the project title. 2Click the ellipsis button and select a subproject in the Subproject dropdown list. 3Click the OK button. 8.3 Mapping Incident Property Fields The mapping of incident property fields between ServiceWise projects, or between a ServiceWise project and a TechExcel DevTrack or TechExcel CustomerWise project, enables project members to submit or copy incidents betweenheterogeneousprojects. Heterogeneous projects are projects that organize and track data differently from one another. Each ServiceWise project may use distinct pages, controls, and fields to manage and track support data. And TechExcel DevTrack projects and TechExcel CustomerWise projects are designed to enable businesses to track entirely different types of data. TechExcel ServiceWise is an extremely customizable application that enables support organizations to define for themselves which data they wish to track and report, and the fields, data types, and control types that are used to manage and describe that data. Consequently, the pages, controls, and the data that is tracked in each ServiceWise may not be consistent with the data that is tracked in other ServiceWise projects. To enable the submission, copying, and linking of incidents across heterogeneous systems, project administrators must first map the fields in one project to fields in other projects. Once the two fields are mapped, the data that is tracked in the mapped field in one project is equated with the data that is tracked in the mapped field in the other project. The following rules apply to mapping fields across projects: Mapped fields must belong to the same data type. Mapped fields are defined on a project-by-project basis. The same field may be mapped to different fields in different projects. Interproject field mapping tasks include: Manually Mapping Incident Fields Automatically Mapping Incident Fields Defining Mapped Field Choices Manually Mapping Incident Fields The mapping of incident property fields between ServiceWise projects, or between a ServiceWise project and a TechExcel DevTrack or TechExcel CustomerWise project, enables project members to submit or copy incidents between heterogeneous projects. The Map button enables administrators to manually map ServiceWise pages and fields on a field by field basis. Project administrators may map incident fields between two ServiceWise projects or between a ServiceWise project and a TechExcel CustomerWise or TechExcel DevTrack project controls in the Field Map tab of the Interproject Settings page. To manually map incident fields between projects: 1Select a project in the project list of the Interproject Copy page. The project must be enabled for the administrator to define incident mapping. A project is enabled for interproject actions when a red check mark appears next to the project title. 2Enable and define incident copying settings. The administrator must enable interproject copying using controls in the General tab. 3Select the Field Map tab. The Map Fields list displays the page title and field title for every field (data-entry control) used to define incident properties in the current project. Project administrators may identify the corresponding page and field for each incident property setting. 4Select a field in the Map Fields list. 5Click the Map button. The Field Map dialog box appears. 6Select page and field options from the Page dropdown list and the Field dropdown list. 7Click the OK button. The Map Fields list displays the field mapping settings. For each multiple choice control (for example, dropdown lists) mapped the administrator may map the options displayed in the multiple choice controls in each project Automatically Mapping Incident Fields Automatic interproject field mapping is the fastest way for project administrators to map fields in two ServiceWise projects, or a ServiceWise project and a TechExcel CustomerWise project or a TechExcel DevTrack project. The Auto Map button enables project administrators to instantly map ServiceWise fields to fields in the linked project. Incorrectly mapped fields may be edited or unmapped. Project administrators may map incident fields between two ServiceWise projects or between a ServiceWise project and a TechExcel CustomerWise or TechExcel DevTrack project controls in the Field Map tab of the Interproject Settings page. To automatically map fields between projects: 1Click the Auto Map button in the Field Map tab. The fields in the ServiceWise project are mapped to fields in the target project. 2Ensure that the fields mapped together are appropriate. 3To edit or unmap mapped fields, select the field in the Map Fields list and click the Map button. Select an appropriate page and field or select theoption. Click the OK button. For each multiple choice control (for example, dropdown lists) mapped the administrator may map the options displayed in the multiple choice controls in each project Defining Mapped Field Choices Project administrators may use the Field Choice Map tab in the Interproject Settings page to map the options that are displayed in mapped multiple-selection controls in linked incidents. For each multiple selection control that the administrator mapped in the Field Map tab, the administrator may now map the options displayed in the control in the ServiceWise project to options displayed in the control of the target project. The Field Choice Map tab is divided into two main areas: The Mapped Field with Multiple Choice list displays every mapped multiple choice control that are mapped between the current project and the target project. Project administrators may map fields using controls in the Field Map tab. Page 55 of 145

56 The Map Field Choice Map list displays the options displayed in a selected multiple choice control in the current project. Project administrators may map the field choice to a field choice belonging to the mapped multiple choice control displayed in the target project. Project administrators may map the field choices for each multiple choice control that is mapped in the Field Map tab. To map incident fields between projects: 1Select a project in the project list of the Interproject Copy page. The project must be enabled for the administrator to define incident mapping. A project is enabled for interproject actions when a red check mark appears next to the project title. 2Enable and define interproject copying settings. The administrator must enable copying using controls in the General tab. 3Map the fields that are used to define incident properties in each project. Project administrators must map the multiple selection controls in the Field Map tab before they can map the field choices belonging to those controls. 4Select the Field Choice Map tab. 5Select a mapped multiple choice control in the Mapped Field with Multiple Choice list. The Mapped Field with Multiple Choice list displays every selection control in the current project that is mapped to a multiple choice control in the target project. The selection control selected determines the options that are displayed in the Map Field Choice Map list. 6Double-click a field choice in the Map Field Choice Map list. The Choice Map dialog box appears. 7Select an option from the Map To dropdown list. The options displayed in the Map To dropdown list represent the list options displayed in the mapped multiple choice control in the target project. 8Click the OK button. The Choice Map dialog box closes Defining Default Field Values for Unmapped Fields To define a default field value or unmapped fields: 1Select a project in the project list of the Interproject Copy page. The project must be enabled for the administrator to define incident mapping. A project is enabled for interproject actions when a red check mark appears next to the project title. 2Define interproject field mappings. 3Define field value mapping for mapped interproject fields. 4Select field mapping in the Mapped Field with Multiple Choices list. The Mapped Field with Multiple Choices list displays the title and field ID numbers of multiple choice controls (such as dropdown lists and combo boxes) in the current project and the corresponding controls in the target project. 5Select the Enable Field Value for Unmapped Field Choice check box. 6Select an option from the Field Value dropdown list. The Field Value dropdown list displays the values that define the mapped field in the target project. 8.4 Administering Linked Issue Employee Web Portal Settings Project administrators may define interproject copying and link rules to manage incidents copied and linked between a ServiceWise project and a TechExcel DevTrack project. Using controls in the Link Info tab, project administrators may define rules for displaying development issue data in the Employee Web Portal and making this information accessible to company employees. Linked issue Employee Web Portal settings administrative tasks include: Displaying Linked Issue Info in the Employee Web Portal Displaying Linked Issue Info in the Web Conversation Page Defining Applicable Incident Workflow States Defining Applicable Link Types Defining Title for Linked Issue Data Adding Linked Issue Information Fields Displaying Linked Issue Info in the Employee Web Portal To display information about DevTrack development issues that are linked to support incidents in the Employee Web Portal, select the Display Linked Info in the Employee Web Portal check box. In each Employee Web Portal, a project administrator must determine which development issues are displayed to company employees. For more information see See Displaying DevTrack Project Development Issues on page Displaying Linked Issue Info in the Web Conversation Page To display information about DevTrack development issues that are linked to support incidents in the ServiceWise client Web Conversation page, select the Display Linked Info in the Web Conversation check box Defining Applicable Incident Workflow States To define applicable incident workflow states, select one or more incident workflow states in the Applicable Incident State list box. An incident workflow state is defined as applicable when a red check mark is displayed adjacent to its title Defining Applicable Link Types To define applicable link types, select one or more incident link types in the Applicable Link Type list box. A link type is defined as applicable when a red check mark is displayed adjacent to its title Defining Title for Linked Issue Data To define a title of linked development issue data in the Employee Web Portal and ServiceWise client Web Conversation page, enter a name in the Linked Issue Info Section Title edit box Adding Linked Issue Information Fields To add linked development issue fields: 1Click the Add button. The Create New Issue Info dialog box appears. 2Select a development issue property in the Field dropdown list. 3Define the title of the label in the Label Name text box. 4Click the OK button. The Create New Issue Info dialog box closes. Chapter 9 Incident Workflow Administration 9 Chapter 9 -- Incident Workflow Administration This chapter explains how project administrators may define workflow rules, incident routing rules, and incident escalation rules to manage the flow of incidents in ServiceWise projects. In this chapter: Page 56 of 145

57 Understanding ServiceWise Project Workflow Administering Incident Workflow Designing ServiceWise Graphical Workflow Administering Incident Routing Administration Incident Escalation 9.1 Understanding ServiceWise Project Workflow Workflow is a business process used to manage the tasks that compose a project. Workflow rules enable project managers to define and track the flow of work between individuals and teams. A well-defined set of workflow rules enable an organization to perform tasks in an efficient and repeatable manner. TechExcel ServiceWise delivers a flexible workflow model that enables project administrators to replicate and enforce their processes in ServiceWise projects. By combining administrator-defined workflow, incident, and incident escalation rules, TechExcel ServiceWise enables administrators to define flexible and powerful process management tools. Project workflow determines the life cycle of ServiceWise incidents. Project administrators may define workflow settings once in TechExcel ServiceWise Admin, all project members will manage incidents according to existing processes. Incident routing enables administrators to define rules for automatically assigning incidents to appropriate project members based on the incident attributes and project member skills and workload. Incident escalation enables administrators to define rules for automatically escalating incident statuses if the due date has passed or if no progress has been made in several days. Project administrators may also enable notifications for all escalations. TechExcel ServiceWise enables each project administrator to define a unique set of workflow rules to manage the incidents in that project. Each work project is managed by its own workflow rules. 9.2 Administering Incident Workflow Administrator-defined workflow rules define the life cycle of incidents in TechExcel ServiceWise projects. Workflow rules enable project administrators to define which states an incidents must go through during its life cycle and how project members may update the incident state of incidents within that project. Project administrators define workflow by defining the workflow model, workflow options, and workflow rules in that project. Incident workflow administrative tasks include: Defining the Project Workflow Model Enabling Workflow Rule Options Creating, Editing, and Deleting Workflow States Defining Applicable Owner Workflow Rules Defining Incident Access (Who Can Change Workflow Rules) Defining Read-Only Field Workflow Rules Defining Invisible Field Workflow Rules Defining the Mandatory Field Workflow Rules Defining Default Submission States Enabling Closed Event Restriction Defining the Project Workflow Model Project administrators may use controls in the Workflow Settings page to select the workflow model that is used to define manage incidents in ServiceWise projects. Project administrators may choose between three options: The No Workflow model The State-dependent Workflow model The Transition-dependent Workflow model The workflow model selected determines how incidents are managed in ServiceWise projects. Project members may submit, update, forward, close, and reopen incidents based on administrator-defined workflow rules. How project members go about managing incidents in a project and which rules an administrator may define and enforce are determined by the workflow model selected. In TechExcel ServiceWise, project workflow may be based on two different models: the state-dependent model or transition-dependent model. The workflow model determines how project members may manage incidents within the project. To select a project workflow model: Project administrators may select one of three options for defining workflow in a ServiceWise project: Status Can Be Freely Changed Without Workflow Restriction:The Status Can Be Freely Changed Without Workflow Restriction option enables project members to freely change the incident state of an incident. Status Change Is Based On Workflow and Via Selecting the Next State:The Status Change Is Based On Workflow and Via Selecting the Next State option enables project members to change the incident state of an incident to the next state in project workflow. This is known as state-dependent workflow. Status Change Is Based On Workflow And Via Performing A State-to-State Transition:The Status Change Is Based On Workflow And Via Performing A Stateto- State Transition option enables project members to change the incident state of an incident to the next state in project workflow by performing an action. This is known as transitiondependent workflow. Each transition represents an action New Section Project administrators may enable and define six different types of workflow rules for each workflow state in the incident life cycle. Next State:Next State rules determine the sequence of workflow states in the incident life cycle. Applicable Owners:Applicable Owner rules determine which project members, groups, or group folders may own incidents in each workflow state. Who Can Change :Who Can Change rules determine which project members, groups, or group folders may update incidents in each workflow state. Read-only Fields:Read-only Fields rules determine which pages or fields are editable in each workflow state. Invisible Fields:Invisible Fields rules determine which pages or fields are visible in each workflow state. Mandatory Fields:Mandatory Fields rules determine which pages or fields are mandatory in each workflow state. Mandatory fields must be completed for an incident to be passed to the next state in project workflow Creating, Editing, and Deleting Workflow States Project administrators may create, edit, or delete workflow states using controls in the Progress States area of the Workflow Setting page. Every workflow state defined in a ServiceWise project is displayed in theprogressstatelist. A workflow state represents a distinct stage in the life cycle of an incident. The workflow states that an administrator defines within a project depends on the incidents managed in that project, and the scope of the project. Project administrators may define four distinct properties whenever they create or edit a workflow state: Name:The Name control enables the administrator to define or edit the name of the workflow state. If Closed:The If Closed control enables the administrator to designate the workflow state as a closing state in the incident life cycle. Project members may close incidents in this workflow state. Customer Access:The Customer Access to the Incident control enables administrators to grant access employees access to incidents in the current workflow state. Project administrators may grant three levels of access to employees: full access, read access, and no access. Comments: The Comments control enables the administrator to add a brief note to the incident that describes its purpose in project workflow Note:Workflow progress states may be created, edited, or deleted in both the Workflow Settings page and in the Workflow Design page Defining Applicable Owner Workflow Rules Page 57 of 145

58 Applicable Owner rules determine which project members, groups, or group folders may own incidents in each workflow state. Project administrators may define a different set of applicable owners for each workflow state in the incident life cycle. Project administrators may use Applicable Owner workflow rules to ensure that only appropriate project members may own incidents in particular workflow states. For example, administrators may not want Level I Support Engineers (an account type) to own incidents in the Development workflow state of the support incident life cycle. Project administrators may wish to restrict ownership of incidents in that workflow state to Level II Support Engineers. Incident ownership may be restricted by account type, user account, team group, group folder: Account Type:Selected account types may be designated as potential owners of incidents in the selected workflow state. Account types are indicated by a # in ServiceWise. For example,#level II Support. Group Folder:Selected group folders may be designated as potential owners of incidents in the selected workflow state. Group folders are indicated by a + in ServiceWise. For example,+new Incidents. Team Group:Selected team groups may be designated as potential owners of incidents in the selected workflow state. Team groups are indicated by a * in ServiceWise. For example,*west Coast Group. User Account: Selected user accounts may be designated as potential owners of incidents in the selected workflow state. Applicable incident owners may also be defined based on previous or existing relationship with an incident. Using one of event different user variables, incident stakeholders may be assigned as applicable owners: {Auto-Assignment}:The {Auto-Assignment} user variable enables incidents to be automatically assigned to project team members based on administrator-defined incident routing rules. {Primary Support Applicable}:The {Primary Support Applicable} user variable enables administrators to designate the primary support engineer for associated customers as potential owners in the selected workflow state. {Primary Support}:The {Primary Support} user variable enables administrators to designate the primary support engineer for associated customers as the default owner in the selected workflow state. {Secondary Support Applicable}:The {Secondary Support Applicable} user variable enables administrators to designate the primary support engineer for associated customers as potential owners in the selected workflow state. {Secondary Support}:The {Secondary Support} user variable enables administrators to designate the primary support engineer for associated customers as the default owner in the selected workflow state. {Submitter}:The{Submitter} user variable enables administrators to define the original submitter of incidents as potential owners of those incidents in the selected workflow state. {Unassigned}:The {Unassigned} user variable enables the administrator to allow incidents in the selected workflow state to be assigned to the Unassigned variable. The Unassigned system variable enables project members to designate incidents as having no owner in a workflow state. To define Applicable Owner workflow rules: Select the Support Applicable Owners check box in the Support Options area of the Workflow Settings page. The Applicable Owners option enables administrators to define the project members, account types, and groups that may own incidents in each workflow state. Select a workflow state in the Progress State list. Select one or more applicable owners in the Applicable Owner tab. The Applicable Owner tab displays the project members, groups, group folders, and user variables that may potentially own incidents in the selected workflow state Action Performer Default Owner Rules In ServiceWise 7, project team members that submit, edit, or forward incidents may be automatically designated as the default owner of those incident based on incident workflow ownership rules. Action performer default owner rules reduces number of clicks that are required to define and assign incidents and improves the flow of incidents. Using controls in the Owner tab of the Workflow Settings page, project administrators may designate the{action Performer} as the default owner of incidents in specific incident workflow states. Assign default ownership of an incident to the user performing the action automatically with the new {Action Performer} setting. The{Action Performer} may be defined as the default owner for unassigned incidents or for incidents where the current owner is applicable or inapplicable Defining Incident Access ("Who Can Change" Workflow Rules) Incident access controls determine which project members, groups, or group folders may change the workflow state of incidents based on workflow states or the transitions between workflow states. Project administrators may enable and define Who Can Change workflow rules in the Workflow Settings page of the Incident Workflow folder. Project administrators may choose one of three options for defining Who Can Change rules in ServiceWise projects: No Support:The No Support option disables Who Can Change workflow rules in the project. Project administrators may not restrict the ability of project members to change incident statuses. State-Based:The Based on Current State option enables administrators to define state-based Who Can Change workflow rules in the project. Project administrators may restrict the ability of project members to change the status of incidents in each workflow state. Who Can Change rules are based entirely on workflow states. Transition-Based:The Based on Transition option enables administrators to define both state-based and transition-based Who Can Change workflow rules in the project. Project administrators may restrict the ability of project members to change the status of incidents in each transition and each workflow state. Who Can Change rules may be based on either transitions or workflow states. Incident access controls may be defined by account type, user account, team group, group folder: Account Type:Selected account types may be designated as potential owners of incidents in the selected workflow state. Account types are indicated by a # in ServiceWise. For example,#level II Support. Group Folder:Selected group folders may be designated as potential owners of incidents in the selected workflow state. Group folders are indicated by a + in ServiceWise. For example,+new Incidents. Team Group:Selected team groups may be designated as potential owners of incidents in the selected workflow state. Team groups are indicated by a * in ServiceWise. For example,*west Coast Group. User Account:Selected user accounts may be designated as potential owners of incidents in the selected workflow state. Incident access controls may also be defined based on previous or existing relationship with an incident. Using one of event different user variables, incident stakeholders may be enabled to updated incidents in particular workflow states: Page 58 of 145

59 {Auto-Assignment}:The {Auto-Assignment} user variable enables incidents to be automatically assigned to project team members based on administrator-defined incident routing rules. {Primary Support Applicable}:The {Primary Support Applicable} user variable enables administrators to designate the primary support engineer for associated customers as potential owners in the selected workflow state. {Primary Support}:The {Primary Support} user variable enables administrators to designate the primary support engineer for associated customers as the default owner in the selected workflow state. {Secondary Support Applicable}:The {Secondary Support Applicable} user variable enables administrators to designate the primary support engineer for associated customers as potential owners in the selected workflow state. {Secondary Support}:The {Secondary Support} user variable enables administrators to designate the primary support engineer for associated customers as the default owner in the selected workflow state. {Submitter}:The {Submitter} user variable enables administrators to define the original submitter of incidents as potential owners of those incidents in the selected workflow state. {Unassigned}:The {Unassigned} user variable enables the administrator to allow incidents in the selected workflow state to be assigned to the Unassigned variable. The Unassigned system variable enables project members to designate incidents as having no owner in a workflow state. To define Who Can Change workflow rules: Select an option from the Who Can Change dropdown list in the Support Options area of the Workflow Settings page. Who Can Change workflow rules may be based on one of three options: No Support Based oncurrentstate Based on Current Transition Select a workflow state in theprogressstatelist. If the Based on Current Transition option was enabled, select a transition in the State list. Select one or more options in the Who Can Change tab. The Who Can Change tab displays the project members, groups, group folders, and system variables that may own incidents in the selected workflow state. Note:If the No Support option is selected in the Who Can Change dropdown list, Who Can Change rules are disabled in the project and the Who Can Change tab is read-only in the Workflow Settings page Defining Read-Only Field Workflow Rules Project administrators may enable and define Read-only Field workflow rules in the Workflow Settings page of the Workflow folder. Read-only Field workflow rules determine which fields (data-entry controls) are editable in the Description page, Current Status page, and employee pages for each workflow state. Read-only fields may be viewed, but not edited. Unlike Read-Only privilege settings, read-only workflow rules apply to all project members regardless of account type. Project administrators may define a unique set of read-only fields for each workflow state in the incident life cycle. To define Read-Only Field workflow rules: Select the Support Read-Only Fields check box in the Support Options area of the Workflow Settings page. The Support Read-Only Fields option enables administrators to define data-entry controls as read-only in each workflow state. Select a workflow state in theprogressstatelist. Select one or more options in the Read-only Fields tab. The Read-Only Fields tab displays the names of data-entry controls displayed in the Description page, Current Status page, and custom pages in the client GUIs. Note:The Read-Only tab is not displayed when administrators select the Closed progress state because all fields are read-only when an incident is closed Defining Invisible Field Workflow Rules Project administrators may enable and define Invisible Field workflow rules in the Workflow Settings page of the Incident Workflow folder. Invisible Field workflow rules determine which data-entry controls are displayed each workflow state. Invisible fields are not displayed and cannot be edited by project members. Project administrators may define a unique set of invisible fields for each workflow state in the incident life cycle. Invisible fields cannot be seen by any project members. Unlike Invisible Field privilege settings, Invisible Field workflow rules apply to all project members regardless of account type. To define Invisible Field workflow rules: Select the Support Invisible Fields check box in the Support Options area of the Workflow Settings page. The Support Invisible Fields option enables administrators to define data-entry controls as invisible in each workflow state. Select a workflow state in the Progress State list. Select one or more data-entry controls in the Invisible Fields tab. The Invisible Fields tab displays the names of data-entry controls displayed in the Description page, Current Status page, and custom pages in the client GUIs Defining the Mandatory Field Workflow Rules Project administrators may enable and define Mandatory Field workflow rules in the Workflow Settings page of the Workflow folder. Mandatory Field workflow rules Page 59 of 145

60 determine which fields must be populated in each workflow state before the incident may progress to the next state in the incident life cycle. Project administrators may choose one of three options for defining Mandatory Field workflow rules in ServiceWise projects: Based on Field Level Only:The Based on Field Level Only option disables Mandatory Field workflow rules and renders the Mandatory Fields tab read-only in the Workflow Settings page. Project administrators may not define Mandatory Field workflow rules in the project. Based on Current State:The Based on Current State option enables administrators to define statebased Mandatory Field workflow rules in the project. Project administrators may mandate that project members define specific incident properties in each workflow state. Mandatory Field workflow rules are based entirely on workflow states. Based on Transition: The Based on Transition option enables administrators to define both statebased and transition-based Mandatory Field workflow rules in the project. Project administrators may mandate that project members define specific incident properties in each workflow state or transition. Mandatory Field workflow rules may be based on either transitions or workflow states. To define Mandatory Field workflow rules: Select an option from the Mandatory Field dropdown list in the Support Options area of the Workflow Settings page. Mandatory Field workflow rules may be based on one of three options: Based on Field Level Only Based oncurrentstate Based on Transition Select a workflow state in the Progress State list. If the Based on Transition option was enabled, select a transition in the State list. Select one or more options in the Mandatory Field tab. The Mandatory Fields tab displays the names of data-entry controls displayed in the Description page, Current Status page, and custom pages in the client GUIs Defining Default Submission States Project administrators may enable and define default state on submission settings for the incidents created in ServiceWise projects in the Workflow Settings page of the Incident Workflow folder. TheDefaultStateon Submission dropdown list displays every workflow state defined in the current project. The workflow state selected by the administrator from thedefaultstateon Submission dropdown list is the default workflow state for all incidents submitted to that project Enabling Closed Event Restriction All child events must be closed before an incident can be closed select this option to ensure all events for an incident are in a Closed state before an incident can progress to the next state 9.3 Designing ServiceWise Graphical Workflow TechExcel ServiceWise enables project administrators to create and define workflow for projects using an intuitive graphical user interface. Project administrators may map and define all workflow states and transitions by drawing state nodes and transition lines in the Workflow Design page of the Workflow folder. Figure 9-1: Workflow Design Page The Workflow Design page consists of two main areas: The Workflow Design flowchart The Workflow Design tool bar Workflow Design tool bar The Workflow Design tool bar displays seven command buttons that enable project administrators to manage and customize flowcharts. Graphical workflow administrative tasks include: Understanding Workflow Design Flowcharts Adding and Editing State Nodes DeletingWorkflowStateNodes Creating and Editing Transition Lines Page 60 of 145

61 Understanding the Graph Properties Manager Customizing State Nodes Customizing Transition Lines Magnifying and Reducing Workflow Flowcharts Saving Workflow Flowcharts Understanding Workflow Design Flowcharts A flowchart is a graphical representation of a process. ServiceWise graphic flowcharts enable project administrators to map out their business processes to any level of detail, to analyze their processes, and to optimize their workflow. In TechExcel ServiceWise project workflow is organized into workflow states and the transitions. Workflow states represent the various stages that an incident may pass through during its life cycle. Transitions link together workflow states. Incidents may only pass from one workflow state to another if a transition exists between those two states. In the Workflow Design page administrators may define project workflow graphically by creating workflow states and transitions. Workflow states are represented by state nodes in the Workflow Design flowchart. Transitions are represented by transition lines in the Workflow Design flowchart. State nodes Every Workflow Design flowchart displays at least three state nodes: a beginning state, an ending state, and an intermediary state. Workflow states (and state nodes) represent a specific stage in the life cycle of an incident. All workflow processes must begin in a New workflow state (represented by the New state node) and end in a Closed workflow state (represented by the Close state node). Each workflow state is represented by a state node in the Workflow Design flowchart. Workflow states may be represented by three different types of state nodes: New} states are represented by a hexagon (six-sided polygon) {Close} states are represented by a square (four-sided polygon) Intermediary states are represented by a square. Note:Project administrators may use controls in the State manager to customize the appearance of state nodes in the Workflow Design flowchart. Project administrators may define the size and color of state node bodies and borders. Transitions Transition lines represent the transitions between workflow states in project workflow. Project administrators may indicate that incidents may pass from one workflow state to another workflow state by drawing a transition line between the corresponding state nodes in the Workflow Design page. Transitions may not be drawn between the New state and the Closed states. Project administrators must create at least one intermediary state, and link the beginning and end of workflow processes to this state. Multiple transitions may be defined between the same two workflow states. Note:Project administrators may use controls in the Transition manager to customize the appearance of transition lines in the Workflow Design flowchart. Project administrators may change the style, color, and text orientation of transition lines Adding and Editing State Nodes Project administrators may add workflow states to project workflow by drawing state nodes in the Workflow Design page. TheAddmanager enables project administrators to define the name of the workflow state and add brief comments describing the purpose of the state in project workflow. Project administrators may only define the name of the workflow state and add a brief description of the state in the Workflow Design page. All other workflow state properties must be defined in the Workflow Settings page. For more information see Administering Incident Workflow. Project administrators may also use the Add a State manager to define the color of the state node body and its border. For more information see Customizing State Nodes. To add a state node: Select the Add a State command. Project administrators may access theaddstatecommand by two methods: Select the State Mode button in the Workflow Design tool bar and place the cursor in flowchart. Drag the cursor across the screen to draw the state node. Lift the cursor to complete the drawing. Right-click in the Workflow Design page and select the Add a State command in the shortcut menu. The Add a State manager appears. Enter a name for the workflow state in the State Name field. Enter a brief description of the state in the Comments field. Optional:To define graphic properties, select options in the State Node Settings area. Click the OK button. The state node is displayed in the Workflow Design flowchart. Note:Project administrators may define workflow rules for the state in the Workflow Settings page. To edit a state node: 1Select the Edit a State command. Project administrators may access theedit a Statecommand by two methods: Double-click a state node in the Workflow Design flowchart. Right-click in the Workflow Design page and select the Edit a State command in the shortcut menu. The Edit a State manager appears. 2Update the workflow state name, comments, and appearance. 3Click the OK button Deleting Workflow State Nodes Project administrators may delete workflow states from project workflow by deleting state nodes in the Workflow Design page. When a workflow state is deleted all incidents in that state must be reassigned to another workflow state. The Merge To dialog box enables project administrators to select a target workflow state that will inherit the incidents that formerly belonged to the deleted state. To delete a state: 1Right-click a state node the Workflow Design page and select the Delete command from the shortcut menu. The Merge dialog box appears. 2Select an option from the Merge To dropdown list. Incidents in the current workflow state are merged into the target workflow state when the current state is deleted. 3Click the OK button Creating and Editing Transition Lines Project administrators may add transitions to project workflow by drawing transition lines between two state nodes in the Workflow Design page. The Add a Transition manager enables project administrators to define the name of the transition and its properties. All other transition properties must be defined in the Workflow Settings page. For more information see Administering Incident Workflow. To create a transition line: 1Select the Transition Mode button in the Workflow Design tool bar. 2Place the cursor in a state node in the Workflow Design flowchart and drag the cursor to the target state node. A transition line is drawn between the two state nodes. Page 61 of 145

62 3Lift the cursor from the flowchart to complete the line. The Add a Transition manager appears. 4Enter a name for the transition in the Transition Name field. 5 Optional:To define graphic properties, select options in the Transition Link Settings area. 6Click the OK button. The transition line is displayed in the Workflow Design flowchart. The target state connected to the original workflow state is designated as a potentialnextstate. Project members may forward incidents from the original workflow state to the target state through the transition Understanding the Graph Properties Manager Project administrators may use controls in the Graphic Properties manager to define the appearance of state nodes in the Workflow Design flowchart. The Graph Properties Manager consists of three tabbed pages: the Chart tab, Box tab and the Arrow tab Customizing State Nodes Project administrators may use controls in the Box tab of the Graphic Properties manager to define the appearance of state nodes in the Workflow Design flowchart. State node graphic properties do not affect or define the workflow rules defined for the corresponding workflow state. Graphic properties merely enable the administrator to represent graphically the purpose of the state represented by the state node in the flowchart. All state nodes are defined by four different properties that the project administrator can define in the Graphic Property Manager. Box properties include: The Box Style property enables project administrators to choose from five different styles: Rect, Ellipse, Round Rect, Rhombus and Polygon The Frame Color property enables project administrators to choose from sixteen different colors: The Fill Color From property enables project administrators to choose from sixteen different colors. The Fill Color To property enables project administrators to choose from sixteen different colors Customizing Transition Lines Project administrators may use controls in the Arrow tab of the Graphic Properties manager to define the appearance of transition lines in the Workflow Design flowchart. Transition line graphic properties do not affect or define the workflow rules defined for the corresponding transition. Graphic properties merely enable the administrator to represent the purpose or importance of the transition within project workflow. Transition lines may be color coded based on the account types or team members that have the privileges to forward incidents using those transitions. Transition lines may be color coded to distinguish primary and subworkflow processes. All transition links are defined by five different properties that the project administrator may define in the Graphic Properties Manager. Transition link properties include: The Arrow Style property enables project administrators to choose from three different styles: Polyline option, Bezier option, Perpendicular option. The Frame and Fill Color property enables project administrators to choose from sixteen different colors. The Text Orientation property enables project administrators to choose from three different styles: Center, Rotate, and Over Longest Segment. The Arrow Head property enables project administrators to choose from five different styles: Arrow, Bow Arrow, Circle, Rhombus, and Triangle. The Arrow Base Size property enables project administrators to enter an arrow width Magnifying and Reducing Workflow Flowcharts Project administrators may use the Zoom In button or the Zoom Out button in the Workflow Flowchart Command area to magnify or reduce the size of the flowchart diagrams presented in the Workflow Flowchart area. The Zoom In button and the Zoom Out button enable administrators to choose the level of magnification to view the details of the flowchart Saving Workflow Flowcharts Project administrators may use the Save button to save copies of the flowchart diagrams presented in the Workflow Flowchart area. Workflow flowcharts are saved as portable network graphics (PNG) files. To save workflow flowcharts: 1Click the Save button in the Workflow Flowchart tool bar. The Save the Graph dialog box appears. 2Choose a destination directory in the Save In dropdown list. 3Choose a destination folder in the Folder list. 4Enter a name for the file in the File Name field. 5Click the Save button. 9.4 Administering Incident Routing Incident routing is an optional feature that enables administrators to define rules for automatically routing ServiceWise incidents to project members based on administrator-defined escalation rules. ServiceWise analyzes incident properties and assigns incidents to the most appropriate person based administrator-defined incident routing rules. Using controls in the Autorouting page under the Advanced Project Settings folder, administrators may define the multiple rules for routing incidents based on incident properties and determine the criteria that is used to assign those incidents to ServiceWise project members. Auto-routed incidents may be assigned to ServiceWise project members based on one of four sets of criteria: Based on project member workloads Based on project member skill levels Based on a formula that is based on the workload and the skill level of potential targets Based on availability administrators may optionally mandate that a user must be logged into a project to be subject to incident routing rules. Incident routing administration is a six step process: Enable incident routing. The administrator must enable incident routing in the project. Optional:Enable incident routing based on team availability. The administrator may choose to mandate that a user must be logged into the project to be subject to incident routing rules. Select an incident routing property. Project administrators may define incident routing rules based on one of three options:the Based on Workload option, the Based on Skill Level Option, and the Based on Formula option. Define a default recipient using the Default Target if No Criteria is Met dropdown list. The administrator defines a default recipient. Define incident routing rules. The administrator defines incident routing criteria in the Auto Routing Criteria section of the Auto Routing page. The incident routing criteria determines which incidents are subject to incident routing rules based on incident properties. Define recipients of auto-routed incidents. The administrator must define which project members receive incidents routed based on incident routing rules. Incident routing administrative tasks include: Enabling Incident Routing Mandating Team Member Availability Incident Routing Understanding Incident Routing Rule Criteria Page 62 of 145

63 Defining Workload Based Incident Routing Rules Defining Skill-Level Based Incident Routing Rules Defining Formula-Based Incident Routing Rules Defining Incident Routing Rules Enabling Incident Routing Note:If both state-dependent workflow rules and incident routing are enabled, be sure to select the {Auto-Assignment} system variable as an applicable owner in the Workflow Settings page in all appropriate states. If the {Auto-Assignment} system variable is not selected for an applicable workflow state, incident routing is not available in that state. Project administrators must enable incident routing in their project before they can define incident routing rules. Enabling incident routing is a two step process: The Auto Routing option must be enabled in the Optional Features page of the General Project Settings folder. The Enable Auto Routing check box must be selected in the Auto Routing page of the Advanced Project Settings folder. The Enable Auto Routing check box must be selected in order for the administrator-defined incident routing rules to be implemented in a ServiceWise project Mandating Team Member Availability Incident Routing The administrator may choose to mandate that a user must be logged into the project to be subject to routing rules. To mandate that project members be logged into a project to be automatically routed incidents, select the Enable Autorouting based on Availability radio button in the Autorouting page of the Advanced Project Settings folder Understanding Incident Routing Rule Criteria Project administrators may use controls in the Routing Property area of the Autorouting page to select the criteria that is used for determining which project member is assigned auto-routed incidents in ServiceWise projects. Project administrators may define incident routing rules based on three different types of criteria. Administrator-defined autoassignment rules may be based Based on the workload of the potential recipients Based on the skill-level to the potential recipients Based on a weighted combination of the skill level and workload of the potential recipients Based on workload (WL) option The Based on Workload (WL) option enables the target with the lowest number of open incidents to be assigned an incident. Based on skill level (SL) option The Based on Skill Level (SL) option enables the target with the highest skill level to be assigned an incident that meets the specified criteria. Based on formula (SL*SW - WL*WW) option The Based on Formula (SL*SW - WL*WW) option enables the incident will be auto-routed based on a weighted formula. The higher the skill level and lower the workload, the higher the probability of an incident being assigned to the target Defining Workload Based Incident Routing Rules Project administrators may define routing rules that are based on the workload of the target owners. Workload-based routing enables project administrators to ensure that the target recipient with the lowest number of open incidents is assigned the routed incident. To define workload-based routing rules the administrator must select the Based on Workload radio button in the Routing Property field, define routing criteria, and target owners. To define workload-based incident routing rules: 1Select the Based on Workload radio button. 2Select a default recipient from the Default Target if no Criteria Is Met dropdown list. Project members, group folders, and the {Unassigned} system variable are displayed as options in the Default Target dropdown list. Note:If an incident is auto-assigned and the incident does not meet routing criteria, ServiceWise automatically assigns the incident to the default target. 3Define routing criteria in the Auto Routing Criteria area. 4Define possible targets in the Possible Target (Owner) area Defining Skill-Level Based Incident Routing Rules Project administrators may define routing rules that are based on the workload of the target owners. Skill-level routing rules enables administrators to ensure that the target recipient with the highest skill level is assigned routed incidents meeting the specified criteria. To define skill-based routing rules the administrator must select the Based on Workload radio button in the Routing Property field, define routing criteria, and target owners. To define skill-based routing rules: Select the Based on Workload radio button. Select a default recipient from the Default Target if no Criteria Is Met dropdown list.project members, group folders, and the {Unassigned} system variable are displayed as options in the Default Target dropdown list. Note:If an incident is auto-assigned and the incident does not meet routing criteria, ServiceWise automatically assigns the incident to the default target. Define routing criteria in the Auto Routing Criteria area. Routing criteria represents a set of incident properties. incidents matching the rule criteria may be assigned to one of the target owners Define possible targets in the Possible Target (Owner) area Defining Formula-Based Incident Routing Rules Project administrators may define routing rules that are based on the workload of the target owners. Formula-based routing rules route incidents to target owners based an administrator defined formula that weighs both the skill level of the potential target owners and the workload of those potential owners: (SL*SW - WL*WW) The lower the workload of the target owner, the higher the probability of an incident being assigned to the target. Page 63 of 145

64 To define formula-based incident routing rules the administrator must select the Based on Formula radio button in the Routing Property field, one or more define incident routing criteria rules, and define potential target owners. The administrator must define the skill-level of each potential target owner in the Possible Target Owner area. To define formula-based incident routing rules: Select the Based on Formula radio button. Click the Formula button. The Formula dialog box appears. Enter a weight in the Skill Level field. Project administrators may define the skill level with a value between 1 and 100. Enter a weight in the Workload field. Click the OK button. The Formula dialog box closes. Select a default recipient from the Default Target if no Criteria Is Met dropdown list. Project members, group folders, and the {Unassigned} system variable are displayed as options in the Default Target dropdown list. Note:If an incident is auto-assigned and the incident does not meet incident routing criteria, ServiceWise automatically assigns the incident to the default target. Define incident routing criteria in the Auto Routing Criteria area. Define possible targets in the Possible Target (Owner) area Defining Incident Routing Rules Project administrators may use controls in the Autorouting Criteria area to add, edit, and delete incident routing rules. Incident routing criteria consist of a set of incident properties. When an incident with these properties is selected for autoassignment, the incident will be assigned to one of the related possible owners. To add an incident routing rule: Click the New Criteria button. The New Routing Rule dialog box appears. Enter a title in Rule Name field. Select a field in the Field Name list. Select a field option in the Selection list. A red check mark appears next to the option when selected. The options displayed in the Selection list represent the options available in the selected field. Click the OK button. To edit incident routing criteria: Select an incident routing rule in the Autorouting Criteria list. Click the Edit button. The Edit Routing Rule dialog box appears. Update a title in Rule Name field. Select a field in the Field Name list. Select a field option in the Selection list. A red check mark appears next to the option when selected. The options displayed in the Selection list represent the options available in the selected field. Click the OK button. To delete incident routing criteria: Select an incident routing rule in the Autorouting Criteria list. Chapter 10 Subproject Administration 10 Chapter10 -- Subproject Administration The subproject hierarchy, represented by the subproject tree in ServiceWise incident view, provides all project members with a visual representation of the support incidents. Subprojects enable support organizations to organize support incidents by support teams, employee types or job descriptions, schedules, or any criteria that is useful or meaningful to the support organization. In this chapter: Understanding Subprojects Defining General Subproject Settings Administering Subproject Status Definitions Defining Subproject Priorities Defining Subproject Access Controls 10.1 Understanding Subprojects ServiceWise subproject management is the process of creating and managing subprojects in a hierarchical tree structure that represents and defines the project work breakdown structure. Project members may create subprojects in the Incident view and define subproject statuses and priorities. Project members may manage subprojects in a TechExcel ServiceWise projects based on subproject privileges that are granted to their account type by a project administrator. Subprojects organize the incidents tracked in a project into discreet subfolders to provide project teams with a clearer and more realistic view of the incidents managed in each project. All ServiceWise support projects may be managed using a combination of subprojects, incidents, and events. Subprojectsare groups of incidents that are organized together by support member teams, serviced employees, or schedules. Subprojects may be used to organize support incidents by any criteria that is useful or meaningful to the support organization. Every subproject has a defined beginning and end and defined relationships with the other subprojects. Every subproject may be the parent of multiple subprojects, which in turn are the parent of child subprojects. Incidentsare the individual tasks that must be completed in the course of the support life cycle. All employee support tasks are represented by support incidents. Subproject workflow rules enable project administrators to define rules for managing the incidents and events that are managed in each subproject and for determining which project members and employees are applicable to a subproject and its incidents and events Administering Subprojects Page 64 of 145

65 Subprojects enable support organizations to better organize and manage the support incidents in a ServiceWise project. Administrator-defined subproject settings define how project members may manage subprojects in a ServiceWise project. subproject status subproject workflow states subproject access controls All subproject configurations and access controls are a project-by-project basis. Subproject settings defined in one project do not affect configuration made to other work projects in the same ServiceWise site. Subproject administrative tasks include: Defining General Subproject Settings Administering Subproject Status Definitions Defining Subproject Priorities Defining Subproject Access Controls 10.2 Defining General Subproject Settings Administrator-defined subproject configurations define how project members may use subprojects to manage incidents in ServiceWise work projects. General subproject settings determine which tools are displayed in the Subproject manager of the ServiceWise clients. Project administrators may enable subproject features and define subproject settings in the General Settings page of the Sub Projects folder. General subproject setting administrative tasks include: Customizing Subproject Terminology Enabling Subprojects in Work Projects Enabling Employee Assignment to Subprojects Enabling Subproject Applicable Owner Controls Restricting Incident Ownership to Subproject Members Restricting Event Ownership to Subproject Members Enabling Subproject Workflow Controls Enabling Subproject Cost Budgets Controls Customizing Subproject Terminology By default, ServiceWise subprojects are referred to assubprojectsin all ServiceWise work projects.support organizations that prefer to use another term may customize the ServiceWise clients to display any name that is more appropriate to their business. To rename subprojects throughout the ServiceWise project, enter a name in the Refer Subproject As edit box control in the General Settings page of the Subproject folder in a ServiceWise work project Enabling Subprojects in Work Projects Subprojects are an optional ServiceWise feature that must be enabled by a project administrator in each ServiceWise work project. To enable support for subprojects in a ServiceWise work project, select an option from the Subproject dropdown list in the General Settings page of the Subproject folder in a ServiceWise work project. The Subproject dropdown list displays three options: Not Enabled:If the Not Enabled option is selected, subprojects are not enabled in the work project and the subproject tree control is not displayed in the Incident view. Enabled and Support One Level of Subproject:If the Enabled and Support One Level of Subproject is selected, subprojects are supported in the work project and project members may create a subproject hierarchy consisting of a single level. Enabled and Support Two Levels of Subproject:If the Enabled and Support Two Levels of Subproject is selected, subprojects are supported in the work project and project members may create a subproject hierarchy consisting of two levels Enabling Employee Assignment to Subprojects To enable employees to be assigned to subprojects, select an option from the Subproject Employee Assignment dropdown list in the General Settings page of the Subproject folder in a ServiceWise work project. The Subproject Employee Assignment dropdown list displays three options: All Employees are Applicable:If the All Employees are Applicable option is selected, all employees are applicable to subprojects in the project. No Employees Can Be Assigned:If the No Employees Can Be Assigned option is selected, employees are not applicable to subprojects in the project. Define Applicable Employees:If the Define Applicable Employees option is selected, project members may define which employees are applicable to subproject in the ServiceWise client. When project members submit incidents to a subproject, only applicable employees are displayed as options in the Subproject Employee control Enabling Subproject Applicable Owner Controls In the ServiceWise client, project members may define which project members may own the incidents managed in that subproject in the Applicable Owners tab of the Subproject manager. Only those project members that are defined asapplicableto a subproject may be assigned support incidents managed in that subproject. Subproject team assignment is an optional ServiceWise feature. Project members may only define applicable incident owners if the Applicable Owners tab is displayed in the ServiceWise client. To display the Applicable Owner tab in the ServiceWise client, select the Enable Team Assignment for Subproject check box in the General Settings page of the Subproject folder in a ServiceWise work project Restricting Incident Ownership to Subproject Members To restrict the ownership of incidents in a subproject to project members that have been designed subproject team members, select the Apply Subproject Project Member Restriction to Incident Owner check box in the General Settings page of the Subproject folder in a ServiceWise work project. Subproject team assignment must be enabled before the project administrator can define subproject incident ownership rules. The Apply Subproject Project Member Restriction to Incident Owner check box is read-only if the Enable Team Assignment for Subproject is not selected Restricting Event Ownership to Subproject Members To restrict the ownership of events in a subproject to project members that have been designed subproject team members, select the Apply Subproject Project Member Restriction to Event Owner check box in the General Settings page of the Subproject folder in a ServiceWise work project. Subproject team assignment must be enabled before the project administrator can define subproject event ownership rules. The Apply Subproject Project Member Restriction to Event Owner check box is read-only if the Enable Team Assignment for Subproject is not selected Enabling Subproject Workflow Controls In the ServiceWise client, project members may define which incidents may be assigned to each subproject based on incident workflow states in the Workflow tab of the Subproject manager. To display the Workflow tab in the ServiceWise client, select the Support Subproject Specific Incident Status check box in the General Settings page of the Subproject folder in a ServiceWise work project Enabling Subproject Cost Budgets Controls In the ServiceWise client, project members may define the planned internal costs and track actual internal costs of the subproject in the Cost Budget tab of the Subproject manager. To display the Cost Budget tab in the ServiceWise client, select the Support Subproject Cost Budget Control check box in the General Settings page of the Subproject folder in a ServiceWise work project Defining Default Subprojects To define the default subproject, select a subproject in the Default Subproject dropdown list of the General Settings page of the Subproject folder in a ServiceWise work project Administering Subproject Status Definitions Page 65 of 145

66 In ServiceWise, a subproject may be defined by asubproject statuswhich indicates the relative status of that subproject and enables project members to better prioritize their work. The criteria that is used to determine the subproject status and the significance of each subproject status is fully customizable in each work project. The subproject status of subproject s in a ServiceWise project may be manually defined by project members in the ServiceWise project or automatically determined based on the incident state of the incidents managed in that subproject. Project administrators may define how the status of subprojects is determined in work projects and rank subproject statuses in the Subproject Status page of the Subproject folder in a work project. All subproject management settings are defined on a project-by-project basis. Subproject status administrative tasks include: Understanding Subproject Status Criteria Defining Independent Subproject Status Settings Defining Derived from Highest Ranked Incident Status Settings Defining Derived from Lowest Ranked Incident Status Settings Defining Linked to Incident Status Settings Understanding Subproject Status Criteria The subproject status of a subproject is based on one of four factors: its subproject workflow state, the incident workflow state of its highest ranked incident, or the incident workflow state of its lowest ranked incident. To define the method that is used to define the subproject status of subprojects in a ServiceWise work project, select an option from the Subproject Status Option dropdown list in the Subproject Status page of the Subprojects folder in a ServiceWise work project. The Subproject Status Option dropdown list displays four options: Independent of its Incidents:The Independent of its Incidents option enables administrators to define a set of subproject workflow states. Derived from the Highest-ranked Incident Status :The Derived from the Highest-ranked Incident Status option links subproject status to the status of the highest-ranked incident within the subproject. If this option is selected the available states for subproject status are the same as the available states for incidents. Derived from the Lowest-ranked Incident Status :The Derived from the Lowest-ranked Incident Status option links the subproject status to the lowest-ranked incident within the subproject. If this option is selected the available states for subproject status are the same as the available states for incidents. Linked to Incident Status Definition option :The Linked to Incident Status Definition option links the applicable subproject workflow states to the incidents workflow states Defining Independent Subproject Status Settings To define independent subproject status settings: 1Select the Independent of its Incidents option in the Subproject Priority Option dropdown list of the Subproject Priority page in the Subproject folder of a work project. 2Define one or more subproject status. 3Define ranks for each subproject status. The lower the number, the higher the ranking for example, a status with a rank of one is ranked higher than a status with a rank of five. The incident with the highestranking status determines the status of the subproject Defining Derived from Highest Ranked Incident Status Settings The Derived from the Highest-ranked Incident Status option links subproject status to the status of the highest ranked incident within the subproject. If this option is selected the available states for subproject status are the same as the available states for incidents. To base subproject priorities on the incident status of the highest ranked incident in a subproject, select the Derived from the Highest-ranked Incident Status option in the Subproject Status Option dropdown list of the Subproject Status page in the Subproject folder of a work project Defining Derived from Lowest Ranked Incident Status Settings The Derived from the Lowest-ranked Incident Status option links the subproject status to the lowest ranked incident within the subproject. If this option is selected the available states for subproject status are the same as the available states for incidents. To base subproject priorities on the incident status of the lowest ranked incident in a subproject, select the Derived from the Lowest-ranked Incident Status option in the Subproject Priority Status dropdown list of the Subproject Status page in the Subproject folder of a work project Defining Linked to Incident Status Settings To define independent subproject status settings: 1Select the Linked to Incident Status Definition option in the Subproject Status Option dropdown list of the Subproject Priority page in the Subproject folder of a work project. 2Select an incident property in the Link to Status dropdown list control. The Link to Priority dropdown list displays multiple properties that define incidents in the work project. For example the Change Type property, the Location property, or the ServiceWise Priority property. 3Define ranks for each subproject status. The lower the number, the higher the ranking for example, a status with a rank of one is ranked higher than a status with a rank of five. The incident with the highestranking status determines the status of the subproject Defining Subproject Priorities In ServiceWise, the relative priority of subprojects in a work project is indicated by theirsubproject priority. The subproject priority of subprojects may be manually defined by the work project team members or automatically defined based on the priority of the incidents managed in that project. Subprojects are prioritized in ServiceWise work projects based on based on one of three criteria: its subproject priority property, the priority of its highest ranked incident, the priority of its lowest ranked incident. Project administrators may choose which criteria is used to define the subproject priority of subprojects in a work project by selecting an option in the Subproject Status Option dropdown list in the Subproject Status page of the Subprojects folder in a ServiceWise work project. Subproject priority administration tasks include: Understanding Subproject Priority Criteria Defining Independent Subproject Priority Settings Defining Derived from Highest Ranked Incident Priority Settings Defining Derived from Lowest Ranked Incident Priority Settings Defining Linked to Incident Priority Settings Understanding Subproject Priority Criteria To define the method that is used to define the subproject status of subprojects in a ServiceWise work project, select an option from the Subproject Status Option dropdown list in the Subproject Status page of the Subprojects folder in a ServiceWise work project. The Subproject Status Option dropdown list displays four options: Independent of its Incidents:The Independent of its Incidents option enables project administrators to define a set of subproject priorities. The subproject priority of a subproject is manually defined by project members in the ServiceWise client. Derived from the Highest-ranked Incident Priority:The Derived from the Highestranked Incident Status option links subproject status to the status of the highest-ranked incident within the subproject. If this option is selected the available states for subproject status are the same as the available states for incidents. Derived from the Lowest-ranked Incident Priority:The Derived from the Lowestranked Incident Status option links the subproject status to the lowestranked incident within the subproject. If this option is selected the available states for subproject status are the same as the available states for incidents. Linked to Incident Priority Definition option:the Linked to Incident Status Definition option links the applicable subproject workflow states to the incidents workflow states Defining Independent Subproject Priority Settings To define independent subproject priority settings: 1Select the Independent of its Incidents option in the Subproject Priority Option dropdown list of the Subproject Priority page in the Subproject folder of a work project. 2Define one or more subproject priorities. 3Define ranks for each subproject priority. Page 66 of 145

67 The lower the number, the higher the ranking for example, a priority with a rank of one is ranked higher than a priority with a rank of five. The incident with the highestranking priority determines the priority of the subproject Defining Derived from Highest Ranked Incident Priority Settings To base subproject priorities on the incident priority of the highest ranked incident in a subproject, select the Derived from the Highest-ranked Incident Priority option in the Subproject Priority Option dropdown list of the Subproject Priority page in the Subproject folder of a work project Defining Derived from Lowest Ranked Incident Priority Settings To base subproject priorities on the incident priority of the lowest ranked incident in a subproject, select the Derived from the Lowest-ranked Incident Priority option in the Subproject Priority Option dropdown list of the Subproject Priority page in the Subproject folder of a work project Defining Linked to Incident Priority Settings To define independent subproject priority settings: 1Select the Linked to Incident Priority Definition option in the Subproject Priority Option dropdown list of the Subproject Priority page in the Subproject folder of a work project. 2Select an incident property in the Link to Priority dropdown list control. The Link to Priority dropdown list displays multiple properties that define incidents in the work project. For example the Change Type property, the Location property, or the ServiceWise Priority property. 3Define ranks for each subproject priority. The lower the number, the higher the ranking for example, a priority with a rank of one is ranked higher than a priority with a rank of five. The incident with the highestranking priority determines the priority of the subproject Defining Subproject Access Controls ServiceWise uses account type-based access controls to implement security in projects. In ServiceWise, project-level privileges are assigned to administrator-defined account types. Project members inherit project-level privileges based on the account type assigned to them in each work project. Subproject access controls define the ability of an employee to access and manage subprojects in a work project including the ability to create, edit, and delete subprojects.: Table 10-1: Subproject privileges Chapter 11 Integration Administration 11 Chapter11-- Integration Administration In this chapter: Understanding ServiceWise Integration Managing Incoming Mail Server Settings Managing Project Sending and Reply-to Addresses Managing the Outgoing Mail Server Managing Templates for Manual Messages Administering Incident Submission Settings Managing Autoreply Settings Managing Autoreply Exclusion Settings 11.1 Understanding ServiceWise Integration integration enables ServiceWise support teams to better manage project incidents, events, and employees by automating and tracking communication conducted by . Using controls in the Advanced Settings folder, project administrators may enable and define -based tools that enable project members to work together more effectively. ServiceWise integration is a prerequisite for the following features: event trackingenables support teams to track every sent to and received from employees through the ServiceWise client asevents. All events are based on administrator-defined received or sent event templates. Project support formultiple incoming addressesenable support teams to better manage and distribute requests from employees. Each project may support multiple team accounts, personal addresses, and personal aliases. The reply to address in project may be based on the team account assigned to the support engineer sending the or the team account assigned to the employee that received the . autoreplyenables support teams to define rules for automatically sending predefined to employees whenever an is received from that employee. Incident autosubmissionenables project members and employees to submit incidents to ServiceWise projects by . ServiceWise automatically creates new incidents based on the content of the subject line and body of the . Incident notificationenables project members to be automatically notified whenever an administrator-defined incident notification rule is triggered. Project administrators may define all appropriate triggers, conditions, and recipients in the Notification page of the Advanced Settings folder Understanding System-Level Integration System-level integration administrative tasks must be completed before project administrators may configure and define project integration settings. System administrators are responsible for installing the ServiceWise Server service, the ServiceWise Retrieval service, and configuring the ServiceWise environment to operate properly. System administrators are also responsible for defining error handling rules. System administrators must install the ServiceWise Server and start the notification service to enable project administrators to implement incident notification in ServiceWise projects. System administrators may install the ServiceWise Server on any Windows server machine. Once installed, the ServiceWise Mail Server service is shown running in the Windows services. The ServiceWise Mail Server is implemented using the SMTP standard and runs as a Windows NT service. Page 67 of 145

68 ServiceWise Database Server and ServiceWise Application Server must be installed before ServiceWise Server can execute properly. The ServiceWise Server may be installed on an existing mail server as long as it is MAPI and SMTP compliant. When the ServiceWise Server is initially installed, it talks to the ServiceWise Application Server to get the database username and password for accessing the ServiceWise Database Server. The ServiceWise Server communicates with the ServiceWise Database Server and sends messages through a POP3 or SMTP mail server: The ServiceWise Server then talks to the ServiceWise Database Server and queries the ServiceWise database for messages that must be sent. When the ServiceWise Server finds messages to be sent, it talks to a POP3/SMTP mail server and send out the s through that mail server. After it has sent the messages, the ServiceWise Mail Server resets flags in ServiceWise Database. The ServiceWise service continues to query the ServiceWise database for new messages that need to be delivered Understanding Events and Event Templates event tracking enables support teams to track every sent to and received from employees through the ServiceWise client as events. All events are based on administrator-defined received or sent event templates. Anevent templateis a set of administrator-defined workflow rules, default event properties, project member access rules, employee access rules, file attachment rules, and notification and escalation rules. event templates may be based on one of two event types: the received event type and send event type. In ServiceWise an event type represents a task and are managed by a set system-defined business rules. received event templates combine administrator-defined workflow rules with system-defined business rules for managing received events. sent event templates combine administrator-defined workflow rules with system-defined business rules for managing sent events. In ServiceWise, events instances of event templates are automatically created in a work project whenever an is received by or send from a team account. Project administrators may create multiple received event templates and multiple sent event templates. Every team account may be assigned a unique set of event templates, with unique owners, due dates, and workflow. The templates assigned to that team account are used to automatically create events whenever an incoming is received or sent from the team account. An received event based on an received event template is created automatically whenever an employee sends an to the support team. An sent event based on an sent event template is automatically created whenever a ServiceWise project member sends an to an employee Managing Incoming Mail Server Settings Incoming settings determine how sent to project team accounts are handled by the ServiceWise system. Incoming are messages sent to the team accounts defined in a ServiceWise project. Team accountsbundle a POP3 or MAPI account (an incoming server, address, user name, and password) with administrator-defined default event templates. messages sent to or from a team account automatically create a events based on the corresponding received or sent event template. Project administrators may enable and define one or more incoming servers, enable the retrieval of incoming from the server, define one or more team accounts, and define the default event templates for received and sent in the ServiceWise client using controls in the Incoming Mail tab of the Integration page in the Advanced Settings folder. The incoming configurations and rules that may be defined in a project, and the data-entry controls displayed in the Incoming Mail page of the Integration page depend on whether the project is using standard integration or advanced integration. If advanced integration is enabled, project administrators may define multiple incoming servers and multiple team accounts. Unique received event templates and sent event templates may be defined for each team account. If advanced integration is not enabled, project administrators may defineoneincoming mail server andoneteam account. All incoming generate events based on the same received event template or sent event template. Incoming server settings include: Enabling Autoretrieval in ServiceWise Projects Enabling Multiple Team Accounts Defining Team Accounts Defining POP3 Server Settings Defining the Reply-to Address of Outgoing Defining Reply To Addresses based on Employee Types Enabling Autoretrieval in ServiceWise Projects ServiceWise projects use the TechExcel ServiceWise Mail Retrieval Server, an NT service, to retrieve from an server using the POP3 or MAPI protocol. To enable and execute autoretrieval in a ServiceWise project, two administrative tasks must be completed: The TechExcel Mail Retrieval Server must be installed on a server machine and the service must be started. The Support Autoretrieval check box must be selected in the Incoming Mail tab of the Integration page. Once started and enabled, the TechExcel Mail Retrieval Server communicates with a designated incoming server and establishes an authorized connection with that server using the user name and password defined in a team account. The Mail Retrieval Server then retrieves addressed to that account. Project administrators may create multiple team accounts and each of those team accounts may connect to a different server using a unique POP3 or MAPI account. To enable autoretrieval in the current project, select the Support Autoretrieval check box in the Incoming Mail tab of the Notification page in the Advanced Settings folder. Note:The Support Autoretrieval check box is grayed out if advanced integration is not enabled in the project. For more information see See Managing Optional Project Features on page Enabling Multiple Team Accounts ServiceWise advanced integration enables projects to support multiple incoming servers and team accounts. Project administrators may define multiple team accounts in each ServiceWise project, and each team account may connect to a different incoming server using its own user name and password. Support teams may wish to use different team accounts to manage messages regarding the various products, services, or locations that are managed by ServiceWise support engineers. Each team account has a unique address, and the address assigned to a team account may indicate the product, service, or location served by that account. Each support project member is assignedoneteam account in each ServiceWise project. Multiple team accounts enable support teams to divide workload across team members based on their expertise, job role, or location. Each team account represents two administrator-defined event templates: an received event template and an sent event template. messages sent to or from a team account automatically create events based on the corresponding received or sent event template. To enable multiple team addresses in the current project, select the Support Multiple Team Addresses check box in the Incoming Mail tab of the Notification page in the Advanced Settings folder. Note:The Support Multiple Team Addresses check box is grayed out if advanced integration is not enabled in the project. For more information see See Managing Optional Project Features. Once a project administrator has enabled support for multiple team accounts, he or she may defined multiple team accounts in the Edit Property manager of the Incoming Mail tab of the Integration tab Defining Team Accounts A team account bundles together a POP3 or MAPI account (an incoming server, address, user name, and password) with two administrator-defined event templates. A project administrator may define one or more team accounts in each ServiceWise project. Page 68 of 145

69 If standard integration is used in a ServiceWise project, the project administrator defines a single team account that connects to a single incoming server. All support engineers in the project share a common team address: for example,support@abcsoft.com. If advanced integration is used in a ServiceWise project, the project administrator may define multiple team accounts that connect to many different incoming servers. Support engineers may be defined different team accounts based on their expertise, job role, location, or any other criteria that makes sense to the business. Project administrators may define team accounts using Edit Property manager in the Incoming Mail tab of the Integration page of the Advanced Settings folder. The address represented by the team account is only used when project members reply to messages send by employees that have not been assigned team accounts. Employees may be assigned team accounts based on their employee type. For more information see Defining Reply To Addresses based on Employee Types. To create team accounts: 1 Optional: To define multiple team accounts, select the Support Multiple Team Account check box in the Incoming Mail tab of the Integration page. 2Click the New button in the Team Accounts area of the Incoming Mail tab of the Integration page. The Edit Property manager appears. 3Choose an protocol for communicating with the incoming server. ServiceWise supports two protocols for retrieving from the server: POP3 and MAPI. To use the POP3 protocol, select the POP3 Protocol to Receive Mails radio button and define POP3 server settings. For step-by-step instructions see See Defining POP3 Server Settings. To use the Microsoft MAPI protocol, select the Microsoft MAPI Protocol to Receive Mails radio button and define the MAPI profile. For step-by-step instructions see See Defining MAPI Server Settings. 4Select a default received event template in the Default Event Template for Received dropdown list. The Default Event Template for Received dropdown list displays all of the event templates created in the project that are based on the Received event type. sent to the team address automatically create events based on the selected event template. Note:Project administrators must define at least one received event template for ServiceWise integration to work. For more information on the received event type see See Project administrators may create multiple event templates based on the Received event type in the Event Templates page of the Event Management folder in the ServiceWise Admin client.. 5Select a default sent event template in the Default Event Template for Sent dropdown list. The Default Event Template for Sent dropdown list displays all of the event templates created in the project that are based on the Sent event type. sent from the team address automatically create events based on the selected event template. Note:Project administrators must define at least one sent event template for ServiceWise integration to work. For more information on the received event type see See Managing Sent Event Templates. 6Click the OK button Defining POP3 Server Settings Project administrators may define unique POP3 account whenever they create a team account in ServiceWise. Each team account bundles together POP3 protocol settings (an incoming server, address, user name, and password) with two administrator-defined event templates. To create POP3 team accounts: 1 Optional: To define multiple team accounts, select the Support Multiple Team Account check box in the Incoming Mail tab of the Integration page. 2Click the New button in the Team Accounts area of the Incoming Mail tab of the Integration page. The Edit Property manager appears. 3Select the POP3 Protocol to Receive Mails radio button. 4Define the name of the incoming mail server in the Incoming Mail Server edit box control. 5Define POP 3 account information of the incoming team address. The Account Information requires a predefined account along with its matching password for the mail server. address account name user name password 6Define the event templates. 7Define the default reply-to address Defining MAPI Server Settings MAPI, themessaging Application Programming Interface, is the proprietary protocol used by the Microsoft Outlook client to communicate with the Microsoft Exchange Server. The TechExcel Mail Retrieval Server (a Microsoft NT service) may use MAPI profiles to retrieve project from a Microsoft Exchange Server. Each MAPI profile represents a set of user information (user name and address), server information, and login information (user name and password) that are defined and stored in a domain. To configure ServiceWise retrieval using the MAPI protocol, project administrators must define MAPI profiles on the server machine and identify those MAPI profiles in appropriate project team accounts. All team accounts are defined in the Incoming tab of the Notification page. Team accounts bundle together an protocol (POP3 or MAPI) with two administrator-defined event templates (an received event template and an sent event template). To define MAPI server settings for team accounts: 1Create a MAPI profile in the domain. Enable the MAPI profile to connect to Microsoft Exchange Server. Page 69 of 145

70 set of user information (user name and address), server information, and login information (user name and password) that are defined and stored in a domain. To configure ServiceWise retrieval using the MAPI protocol, project administrators must define MAPI profiles on the server machine and identify those MAPI profiles in appropriate project team accounts. All team accounts are defined in the Incoming tab of the Notification page. Team accounts bundle together an protocol (POP3 or MAPI) with two administrator-defined event templates (an received event template and an sent event template). To define MAPI server settings for team accounts: 1Create a MAPI profile in the domain. Enable the MAPI profile to connect to Microsoft Exchange Server. Define user information including a user name and an address. Define the server information. Define login information including the user name and password. 2Install a Microsoft Outlook client (or another MAPI-compliant client) on the same machine as the one running the TechExcel Retrieval Server service. The client is only used to create the MAPI profiles. 3Log into the Microsoft Exchange Server using the MAPI profile and set up the Microsoft Outlook client. 4Log into the Microsoft Outlook client using the MAPI profile. 5Ensure that the MAPI profile may send and receive using the Microsoft Outlook client. 6Create a team account in the ServiceWise Admin client. The TechExcel Retrieval Server uses the MAPI profile identified by the team account to log into the Microsoft Exchange Server and retrieve incoming Defining the Reply-to Address of Outgoing Project administrators may define an address as the default reply to address for all incoming project . To define the default reply to address for sent from the ServiceWise project, select an option from the Default Team Address dropdown list in the Incoming Mail tab of the Integration page in the Advanced Settings folder. The Default Team Address dropdown list displays every administrator-defined team account created in the project. The default address for reply is the reply to address that is used if no other address is acceptable. The sending address for these replies to employee may be one of three addresses: the reply to address of the project member, the reply to address of the employee, or the default reply to address. In most circumstances the sending address used for replies to incoming is the reply to designated in the team address that is assigned to the project member. The sending address used for replies to incoming may be based on reply to designated in the team address assigned to the employee that sent the original . Employees may be assigned team accounts based on their employee type. For more information see Defining Reply To Addresses based on Employee Types. The default reply to address is only used if two conditions are met: The default address defined in the General Settings tab of the Integration page is set to the Team Address Based on Employee Type option and the employee sending the incoming has not been assigned a team account Defining Reply To Addresses based on Employee Types In ServiceWise projects, project members may quickly reply to all project sent by employees regarding ServiceWise incidents. The sending address of reply s may be based on one to three administrator-defined addresses: the reply to address of the project member, the reply to address of the employee, the default reply to address. The employee reply to address is used when the following criteria is met: The address defined in the General Settings tab of the Integration page is set to the Team Address Based on Employee Type option. The employee that sent the original (the that the project member is replying to) is assigned a team address based on their account type. In this configuration, the reply to address displayed in the sent to employees is not based on the team address assigned to the project member, but the team address assigned to the employee type of the employee receiving the . To define team addresses based on employee types: 1Click the Team Addresses for Customers button in the Incoming Mail tab of the Integration page in the Advanced Settings folder. The Team Addresses for Customers dialog box appears. 2Double-click an employee type in the Employee Type list. The Define Address for Employee Type dialog box appears. 3Select an administrator-defined team account and click the OK button. The address is assigned to the employee type. 4Click the OK button Managing Project Sending and Reply-to Addresses Project administrators may create multiple team accounts and assign these accounts to project members based on various administrator-defined criteria. The reply to address displayed in project is derived from on one of four sources: Team addresses Team addresses based assigned to support engineers and employees Personal addresses defined at the system level Personal aliases defined at the project level All sent to employees by project members from within the ServiceWise client display one of two types of addresses as the reply to address: the team account address or the personal address of an individual project member. The team account address represents a standard address that is used by all project members assigned to corresponding team accounts. A typical team address issupport@abcsoft.com. The personal address represents the personal address of a support engineer or an alias that appears to be a personal address (for example, pmiller@abcsoft.com), but which is actually a standard team address (support@abcsoft.com.). Project administrators may define the default sending address for all sent from within the TechExcel ServiceWise project using tools in the General Settings page of the Integration page in the Advanced Settings folder. To define team addresses based on contact types or personal aliases the project administrator must enable advanced integration. For more information see See Managing Optional Project Features on page integration tasks include: Enabling Team Reply-to Addresses Enabling Personal Addresses as Reply-to Addresses Enabling Personal Aliases as Reply-to Addresses Enabling Personalized Reply Name Enabling Project Members to Choose Reply Addresses Enabling Team Reply-to Addresses Project administrators may enable the use of team addresses as the reply to address in project in the General Settings tab of the Integration page of the ServiceWise Admin client. A team account address is a standard address that is used by all support engineers assigned to a particular team account. Every project member may be assigned the team account that best represents their role in the project. Project administrators may create multiple team accounts to represent different groups, locations, products, titles, or any other criteria they choose. A typical team address issupport@abcsoft.com. Team addresses may be based on two different options: The Team Account Assigned To Project Member option identifies the team account assigned to the project member as the default reply to address for project . The Team Address Based on Employee Type option identifies the team account assigned to the employee as the default reply to address for project based on their employee type Enabling Personal Addresses as Reply-to Addresses In ServiceWise, a personal address represents the personal address of a ServiceWise user as defined and managed in the base project by a system administrator. Project administrators may enable personal addresses to be used as reply to addresses in the General Settings tab of the Integration page of the ServiceWise Admin client. Reply to addresses may be based on four different factors: personal accounts, personal aliases, team accounts assigned to support engineers, or team accounts assigned to employees based on their employee type. To enable personal address reply-to addresses: 1Enable advanced settings in the Optional Settings page of the General Project Settings folder. If Advanced Integration has not been enabled, the advanced settings controls are grayed out in the General Settings tab of the Integration page. For more information see See Managing Optional Project Features on page 106. Page 70 of 145 2Select the Support Personal Address check box in the General Settings tab of the Integration page. If the Support Personal Address option is not enabled, all sent to employees from within the ServiceWise client uses a team account as the reply to address. 3Select the Project Member Address Defined in Support Member Manager option from the Default Reply Address dropdown list. The Project Member Address Defined in Support Member Manager option defines the sending address as the personal address of the project member as

71 more information see See Managing Optional Project Features on page Select the Support Personal Address check box in the General Settings tab of the Integration page. If the Support Personal Address option is not enabled, all sent to employees from within the ServiceWise client uses a team account as the reply to address. 3Select the Project Member Address Defined in Support Member Manager option from the Default Reply Address dropdown list. The Project Member Address Defined in Support Member Manager option defines the sending address as the personal address of the project member as defined in the Support Member manager. Project administrators may define project member account types, team address, and personal address in the Project Member Properties dialog box of the ServiceWise Members page. For more information see Understanding Project Member Addresses Enabling Personal Aliases as Reply-to Addresses Project administrators may enable the use of personal aliases as the reply to addresses in project in the General Settings tab of the Integration page of the ServiceWise Admin client. A personal address represents the personal address of a support engineer or an alias that is displayed as a personal address in (for example, pmiller@abcsoft.com), but which is actually a standard team address (support@abcsoft.com.). To enable personal aliases as reply-to addresses: 1Enable advanced settings in the Optional Settings page of the General Project Settings folder. If Advanced Integration has not been enabled, the advanced settings controls are grayed out in the General Settings tab of the Integration page. For more information see See Managing Optional Project Features on page Select the Support Personal Address check box in the General Settings tab of the Integration page of the Advanced Settings folder. If the Personal Address (Alias) option is not enabled, all sent to employees from within the ServiceWise client use the project member s team address as the reply-to address. Project administrators may define a project members account type, team address, and personal address in the Project Member Properties dialog box within the ServiceWise Members page. For more information see See Understanding Project Member Addresses on page Select the Personal Address Defined in this Project option from the Default Reply Address dropdown list. The TechExcel ServiceWise Personal Address (Alias) option identifies the project member personal address (alias) as the reply address. The project members personal address in TechExcel ServiceWise is defined as an alias of the team address. The TechExcel ServiceWise Personal Address (Alias) option is only displayed in the Default Reply Address dropdown list if advanced integration is enabled in a project Enabling Personalized Reply Name To enable project members to define a personalized name for replies to project , select the Enable Personalized Reply Name check box Enabling Project Members to Choose Reply Addresses Project administrators may enable project members to choose whether the they send to employees from within the ServiceWise client include the standard team address assigned to them or their personal address. To enable project members to choose whether to use their team account address or their personal address as the reply to address for sent to employees, select the Allow Project Members to Choose Reply Address when Sending s check box in the General Settings tab of the Integration page. If the Allow Project Members to Choose Reply Address when Sending s check box is not selected, the default reply address is used Defining Notification Send From Properties Project administrators may define the name of the sender and the sending address of notification messages using controls in the General Settings tab of the Integration page. The From Address field enables the administrator to define the address that is displayed in the client as the originating address of all notifications. The From Name field enables the administrator to define the name that is displayed in the client as the sender of all notifications Managing the Outgoing Mail Server Project administrators may define the SMTP outgoing mail server properties in the Outgoing Mail Server tab of the Integration page. Outgoing server settings enable project members to send to employees from with the ServiceWise client and the ServiceWise notification engine to send notification messages to project members and employees. To define outgoing mail server properties: 1Select the Outgoing Mail Server tab in the Integration page of the Advanced Features folder in the ServiceWise Admin client. 2Define the name or the TCP/IP address of the outgoing mail server. 3 Optional: If the outgoing mail server requires authentication, select the My Mail Server Requires Authentication check box and specify required user account information. The account information can be either a domain user account or the server computer account with privileges of using the outgoing mail server service. 4Define the default sending address for all sent from within the ServiceWise project in the Default From Address edit box control. 5Select a default sent event template in the Default Event Template for Sent dropdown list. The Default Event Template for Received dropdown list displays all of the event templates created in the project that are based on the Sent event type. sent from the team address automatically create sent events based on the selected event template. Note:Project administrators must define at least one sent event template for ServiceWise integration to work. For more information on the received event type see Managing Sent Event Templates Managing Templates for Manual Messages Project administrators may create, edit, and manage templates for three different types of messages that may be sent from within the ServiceWise client: incident , resend, and reply. Incident are messages that are manually sent to employees regarding a ServiceWise incident. Resend are messages that are manually sent to employees regarding a ServiceWise incident. Reply are messages that are manually sent to employees regarding a ServiceWise incident. An template is a predefined message that project members may use to create personalized messages within the ServiceWise client. All messages based on templates may be edited by project members before the is sent to the employee. The template prepopulates the fields of an with standard salutations, contact information, or other information. System variables may also be added to display incident data in messages. Project administrators may define both the content and the layout of messages using built-in text editors Managing the Incident Template The Incident template is a predefined messages that support engineers may use to create incident messages in the ServiceWise client applications. Project administrators may define an Incident template in the Integration page of the Advanced Settings folder in the ServiceWise Admin client. Project administrators may add system variables to the subject, body header, body, and signature of the Incident template that represent various incident properties. Whenever an is created based on the Incident template, appropriate incident property values are substituted for the system variables in the body of the message. Note:The numbers in parenthesis represent the field number of the control represented by each incident property variable. Incident property variables include: Project NameTitle (101) Description (102)Problem Type (103) Problem Detail (104)Database (105) Next State (490)Attach (499) Progress Status (601)Work Description (605) Customer access (614)Support Plan (615) Response time options (617)SLA details (618) Data Grid (630)Work Around (12) Page 71 of 145

72 Satisfaction Level (13)Request Type (14) Customer Priority (15)Multiple Selection Control (2123) [Incident Change Summary][Recipient List] [Knowledge and Notes][Incident History] [Web Conversation][Customer Information] [Primary Contact][Incident Contact] To customize the incident template: 1Click the Incident button in the in the Integration page of the Advanced Settings folder in the ServiceWise Admin client. The Notification manager appears. 2Define the default title of the template. 3Define a header for the body of the template. 4Define the body of the template. 5Define the signature of the template. The Signature control enables administrators to define a standard signature to attach to all s sent from the current project. 6Click the OK button Managing the Resend Template The Resend template is a predefined message that serves as a template for creating resend messages in the ServiceWise client applications. Project administrators may customize the resend template in the Integration page of the Advanced Settings folder in the ServiceWise Admin client. Project administrators may customize the body header and signature of the resend template. To customize the resend template: 1Click the Resend button in the in the Integration page of the Advanced Settings folder in the ServiceWise Admin client. The Header and Signature manager appears. 2Define a header for the body of the template. 3Define the signature of the template. 4Click the OK button Managing the Reply Template The Reply template is a predefined message that serves as a template for creating reply messages in the ServiceWise client applications. Project administrators may customize the reply template in the Integration page of the Advanced Settings folder in the ServiceWise Admin client. Project administrators may customize the body header and signature of the reply template. To customize the reply template: 1Click the Reply button in the in the Integration page of the Advanced Settings folder in the ServiceWise Admin client. The Header and Signature manager appears. 2Define a header for the body of the template. 3Define the signature of the template. 4Click the OK button Administering Incident Submission Settings ServiceWise incident submission rules enable employees to submit support incidents in ServiceWise projects by sending messages to a predefined team account. An incident submission rule defines the rules that enable a group of employees to submit support incidents to a ServiceWise project by sending an messages to an applicable team account. All incident rules are defined for employee groups. Project administrators may define the incoming mail server, the outgoing mail server, and specify which account types may submit incidents through in the Integration page. incident submission administration tasks include: Defining Employee Groups Managing Incident Field Mapping Understanding Incident Submission Formats Designing Incident Templates Defining Employee Groups An incident submission rule defines the rules that enable a group of employees to submit support incidents to a ServiceWise project by sending an messages to an applicable team account. An employee group represents a set of incident submission rules that are defined for a specific group of employees. Every employee group is defined by a employee type, one or more applicable team accounts, and optional incident autocreation and incident field mapping rules. Project administrators may enable optional incident autocreation rules for each employee group. If this option is enabled, the ServiceWise Mail Retrieval Server parses the and automatically converts the message into an ServiceWise incident based on administrator-defined rules. To define a employee group: 1Click the Add New button in the Integration page of the Advanced Settings folder in a work project. The Employee Group to be Autosubmitted dialog box appears. 2Define the name of the employee group in the Group edit box control. 3Select an employee type option in the Employee dropdown list. The Employee dropdown list displays every employee type created in the parent base project and the {None} and {Unregistered} system variables. 4Define one or more applicable team addresses in the Addresses edit box control. A team account represents an administrator-defined account and an event template. For more information see Defining Team Accounts. Note: 5 Optional:To enable incident autocreation from incident submissions. auto submission automatically create incidents based on received from applicable employees. 6To enable field mapping, select this to enable the mapping button. Page 72 of 145

73 Project administrators may define detailed field mappings to more clearly define incident date Enabling Field Mapping In ServiceWise, project members and employees may submit support incidents to work projects by sending structured messages to a defined address. ServiceWise automatically creates new support incidents based on the content of the subject line and body of the . To enable field mapping: 1Add or edit an employee group in the Auto Submit tab of the Integration page of the Advanced Settings folder. 2Define a employee group in the Employee Group to be autosubmitted manager. Only project members that belong to an administrator-defined incident submission group may submit incidents by . 3Select the Support Field Mapping check box in the Employee Group to be Autosubmitted dialog box Customizing Field Mappings Tags In ServiceWise, project members and employees may submit support incidents to work projects by sending structured messages to a defined address. ServiceWise automatically creates new support incidents based on the content of the subject line and body of the . Incident submission messages may incident custom submission tags that represent incident property variables. All submission tags may be customized. Project administrators may define field mappings between incident fields and submission tags and the field delimiters that are used to identify those tags in the body of the submission message. Project administrators may map incident fields to customized tags in the Field Mapping manager and define the field delimiters that are used to identify those tags in incident submission messages. To edit the name of custom tags: 1Select the Mapping button. The Field Mapping dialog box appears. 2Select an incident field in the Field Mapping list. 3Click the Edit button. The ServiceWise Field dialog box appears. 4Define the name of the custom tag in the Mapped Name text box. 5Click the OK button. The ServiceWise Field dialog box closes. To define custom tag field delimiters: 1Select the Mapping button. The Field Mapping dialog box appears. 2Click the Change Field Delimiter button. 3The Define Field Delimiter for Auto Submit dialog box appears. 4Enter a field delimiter in the Field Delimiter text box. ServiceWise incident submission supports four different characters as field delimiters for custom tags: chevrons: braces: {FIELDNAME} brackets: [FIELDNAME] parentheses: (FIELDNAME) 5Click the OK button. 6The Define Field Delimiter for Auto Submit dialog box closes Managing Incident Field Mapping Project administrators may define the relationship between the incident properties defined in the and the incident property fields managed in the ServiceWise database by defining -mapping rules in the Field Mapping manager. The Field Mapping Manager displays a list of every incident property field in the current project. Project administrators may define an alias for each of these fields that employees may add to incident submission . Note:ServiceWise Auto Submission supports all system and custom-defined incident property fields. Define mappings between the ServiceWise database and the format. Employees can then use the body (with proper formatting) to define multiple fields on the incident description and current status page. To define field mappings: 1Define a employee group in the Employee Group to be autosubmitted manager. Only project members that belong to an administrator-defined autosubmission group may submit incidents by . 2Enable support for field mapping. 3Select the mapping button. The Field Mapping Manager appears. The Field Mapping manager displays every incident property field used in the current project. 4Select a incident property field in the Field Mapping list and click the Edit button. The ServiceWise Field dialog box appears. 5Enter an alias for the incident property field in the Mapped Name edit box control and click the OK button. The incident property alias is displayed in the Field Mapping list Defining Field Mapping To enable field mapping: Understanding Incident Submission Formats Project members and employees may submit new incidents to ServiceWise projects and define incident property values by sending conforming to a specific format to an administrator-defined address. The subject line of the automatically defines the title of the new incident. The body of the may be used to provide a brief description of the incident and to define multiple incident property fields. file attachments are converted to incident attachments. Employees may create messages that create new incidents and define multiple incident property fields by using markup tags to identify incident fields in the body of the . To define multiple fields by incident submission, the body of the must be divided into two sections using the [Incident Properties] and [Description] tags. The [Incident Properties] tag identifies the beginning of the incident property definitions. Employees may define appropriate values for each incident property. The employee-defined field names and values must match the incident property aliases Chapter 12 Event Administration 12 Chapter12 -- Event Administration In this chapter: Understanding ServiceWise Events Defining General Event Settings Managing System Event Templates Managing Definable Event Templates Administering General Event Template Properties Page 73 of 145

74 Administering Global Event Templates Administering Event Submission Access Controls Administering Event Editing Access Controls Administering Event Attachment Rules Managing Regular Event Templates Managing Asset Operation Event Type Event Templates Managing Autodiscovery Asset Event Templates Managing Announcement Event Templates Managing Received Event Templates Managing Sent Event Templates Defining Knowledge Management Event Templates Defining Power User Event Templates Defining Quick Letter Event Templates Administering Event Workflow Administering Advanced Event Workflow 12.1 Understanding ServiceWise Events TechExcel ServiceWise tracks day-to-day business activity as events. Events represent the to do items that project members must perform in the course of processing incidents. Typical events include calling or receiving a call from an employee, employee requests for equipment, an online meeting or visit to a site, receiving or sending , or approval from management Events and incidents As incidents progress through the incident life cycle, changing workflow states and owners, events may be attached to those incidents to support multi-tasking, track day-to-day activities, and enhance incident workflow. Support incidents may be open days, weeks, or even months, and events provide a way of tracking the daily tasks and actions taken to help resolve incidents. A single incident may require one or more events to be recorded as part of the support effort or as part of communicating with an employee events may represent simple tasks, randomly occurring events, or employee inputs. Events may be general events or incident-specific events. General events are not linked to support incidents. Incident-specific events are associated with one-and-only-one incident at all times in project workflow Understanding Event Administration All events are based on administrator-defined event templates. Aevent templateis a set of rules for managing events in project workflow. The life cycle of a development event and the rules that determine how that event is managed in workflow are defined by the event template that was used to create it. Event administration, therefore, is the largely a matter of creating event templates, defining the rules that manage events based on that template, and determining when events based on that event template may be created in the project Understanding Event Types Anevent typerepresents the many different types of tasks that project members must perform in the course of managing incidents. Making phone calls, sending and receiving , and adding documents to the knowledge base all represent very different processes and are managed by distinct business rules in ServiceWise projects. Each event type represents business logic that determines which tools and processes are used to manage events of that type. The event type defines the business rules that are built into that event template. All event templates belong to one of two classes of event types: definable event types or system event types Definable event types A definable event type represents a system-defined set of business rules that determine how events of a particular type are managed in a project. Project administrators may create multiple event templates for each event type and define customized workflow rules for each event template. ServiceWise features nine definable event types. Each definable event type is designed to manage a particular type of event and consists of business rules tailored to that event type. Definable event types may be used to create event templates in a work project. Project administrators may create multiple event templates for each of the nine definable event types: asset operation event type:the asset operation event type defines a set of asset management business rules. co-owner event type:the co-owner event type defines a set of business rules for managing co-owner events. announcement event type:the announcement event type defines a set of business rules for managing blasts. received event type:the received event type defines a set of business rules for managing sent from an employee to a team account. sent event type:the received event type defines a set of business rules for managing sent from a team account to an employee. knowledge management event type:the knowledge management event type defines a set of asset management business rules. power user event type:the power user event type defines a set of business rules for managing power users. Quick Letter event type:the quick letter event type defines a set of Quick Letter management business rules. regular event type:the regular event type defines a set of business rules for managing regular events such as calling employees, receiving calls from employees, requests for equipment, attending meetings, conducting online meetings, and so on System event types A system event type represents a set of business rules that determine how events of a particular type are managed in a project. Project administratorsmay notcreate event templates based on system event types. ServiceWise features five system event types. The Download event template The Incident File event template The Interproject Copied event template The Newly Registered User event template The Request for Password event template 12.2 Defining General Event Settings Project administrators may rename the events in the project and to enable the Calendar view in the ServiceWise clients in the General Settings page of the Event Management folder. General event settings include: Renaming Events in ServiceWise Projects Enabling the Calendar View Renaming Events in ServiceWise Projects Project administrators may define a custom term for the Event business object in the General Settings page of the Event Management folder By default, the termeventis used to refer to a task or subincident that makes up an incident in ServiceWise projects. The termeventis displayed throughout the ServiceWise Admin client and the ServiceWise clients. Project administrators may substitute another term that better describes their workflow processes. To customize the name given to events, enter a custom name in the Refer Event As control in the General Settings page of the Event Management folder of the ServiceWise Admin client. Page 74 of 145

75 Enabling the Calendar View The Calendar view in the ServiceWise client enables project members to plan, view, and create new events in monthly, weekly, and daily calendars. Figure 12-1: Calendar View in the ServiceWise Web Client Using controls in the Search bar, project members may filter the events displayed in the calendars based on employee, owner, event template, event type, and due date. To display the Event Calendar view in the ServiceWise client applications, select the Enable Event Calendar View check box in the General Settings page of the Event Management folder of the ServiceWise Admin client Managing System Event Templates A system event type is a predefined event. Project administrators may create event templates based on system event types. System events may be used to track employee actions in a ServiceWise project such as employee self-registration or downloads from the site. System event types include: The Download event template The Incident File event template The Interproject Copied event template The Newly Registered User event template The Request for Password event template 12.4 Managing Definable Event Templates Everyeventcreated in a ServiceWise project is aninstanceof an event template and inherits administrator-defined settings from that template and system-defined business rules from its event type. Events are managed by two sets of rules in ServiceWise projects: administrator-defined workflow rules and system-defined business rules. Administrator-defined workflow rules determine how events may be managed byproject membersin a ServiceWise project. System-defined business rules determine how events are processed by theservicewise application. Each event type represents business logic that determines which tools and processes are used to manage events of that type. Anevent templateis a set of administrator-defined workflow rules, default event properties, project member access rules, employee access rules, file attachment rules, and notification and escalation rules. Every event template is based on one of nine definableevent types.anevent typerepresents a set of system-defined business rules Project members are responsible for creating event templates based on system-defined event types, defining event template workflow rules, and making event templates available to project members in the ServiceWise client applications. Project administrators may create and define event templates based on nine different event types: Asset Operation Event event type, Co-owner Event event type, Announcement Event event type, Received Event event type, Sent event type, Power User event type, QuickLetter Event event type, and the Regular Event event type. Creating event templates based on different event types requires that the administrator configure many different data-entry controls in the Event Templates page of the Event Management folder. Many of the data-entry controls or configuration settings areuniqueto some of the event types. However, may event template configuration tasks are universal to all event template regardless of the event type. To properly define an event template, a project administrator must perform seven basic tasks: Create the event template and select an event type. Define event properties. Define event submission rules Define event editing rules Define event deletion rules Define event attachment rules Each of these tasks are described in general in this section. Detailed instructions for defining event template settings that are specific to event templates based on a particular event type should look to the relevant sections. Event template management tasks include: Creating Event Templates Deleting Event Templates Creating Event Templates Anevent templateis a set of administrator-defined workflow rules, default event properties, project member access rules, employee access rules, file attachment rules, and notification and escalation rules. Project administrators may create any number of event templates for each of the nine definable event types: asset operation event type autodiscovery asset event type co-owner event type announcement event type received event type sent event type Page 75 of 145

76 knowledge management event type power user event type Quick Letter event type regular event type Project administrators may create event templates and define unique workflow rules for each event template in the Event Templates page of the Event Management folder. To create an event template: 13Click the New button in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears. 14Define a unique descriptive name for the event template in the Name text edit box control. The Name property identifies the unique name of the event template. The event template name is the default name for all user-defined events that are based on the selected event template. 15Enter a brief description of the event template in the Description text edit box control. The Description property provides a brief description of the workflow rules represented by the event template. The event template description is the default description for user-defined events that are based on the selected event template. 16Select an event type option the Event Type dropdown list control. The Event Type dropdown list displays nine event type options: asset operation event type autodiscovery asset event type co-owner event type announcement event type received event type sent event type knowledge management event type power user event type Quick Letter event type regular event type The Event Type property defines the event type represented by the event template. The event template may be used to create events belonging to the selected event type. 17Click the OK button. The event template is displayed in the Event Templates list. Project administrators may define event workflow rules for the event template. 18Define event workflow states. For step-by-step instructions see See Creating Event Workflow States. 19Define applicable event owner rules. For step-by-step instructions see See Creating Event Workflow States. 20Define event start dates and due dates. For step-by-step instructions see See Creating Event Workflow States. 21Enable or disable employee access. For step-by-step instructions see See Creating Event Workflow States. 22Define the event scope. For step-by-step instructions see See Defining Start Dates and Due Dates. 23Define template identifier. For step-by-step instructions see See Defining Event Template Identifiers Deleting Event Templates To delete an event template, select the event template in the Event Template list control and click the Delete button Administering General Event Template Properties All general event template properties may be defined in the Property tab of the Event Templates page of the Events folder. General event template administrative tasks include: Defining Start Dates and Due Dates Defining the Event Template Scope Defining the Prefix and Help Notes Defining Event Number Restrictions Defining Event Template Identifiers Defining Start Dates and Due Dates The start and due dates represent the beginning and ending of events. Project administrators may determine these settings may be defined, managed, and tracked for all events based on an event template. Project administrators may define or update default values, offset times, and employee access settings for event template start and due dates in the Property tab of the Event Template page in the Event Management folder of the ServiceWise Admin client. Project administrators may make six different customizations to each control: Define the field label that identifies the data-entry control. Enable default values to be entered in the data-entry controls based on the date that the event is created. Define day, hour, and minute offset settings. Define the data-entry controls as visible or invisible. Enable display of the time Define employee access to the data-entry controls. Each control may be defined as invisible, read-only, or editable for employees. To customize Event Template date controls: 1Select an event template in the Event list control of the Event Templates page. 2Double-click the Start Date control or Due Date control in the Property tab. The Event Templates Edit Box appears. 3 Optional:To customize the field label that identifies the data-entry control, enter a unique name in the Field Label control. 4 Optional:To enable default values to be displayed in the data-entry control, select the Assign Default Value based on Current Time radio button in the Default Values area of the Property tab. 5 Optional:To define offset times for the days, minutes, and hours tracked in the data-entry controls, select an option in the Day, Hour, and Minute controls. Page 76 of 145

77 6 Optional:To define the data-entry control as visible to project members, select the Visible check box in the Field Attributes area. 7 Optional:To enable the data-entry control to display times to project members, select the With Time check box in the Field Attributes area. 8 Optional:To define employee access to the data-entry control, select an option in the Employee Access area. Select the Not Visible radio button to define the data-entry control as invisible to employees. Employees cannot view or edit control settings. Select the Read Only radio button to define the data-entry control as read-only to employees. Employees may view, but cannot edit control settings. Select the Edit radio button to define the data-entry control as editable to employees. Employees may view and edit control settings. 9Click the OK button Defining the Event Template Scope The scope of an event determines when and how that event may be created in a ServiceWise project. Every ServiceWise event may be a general event or an incident-specific event. General events are not linked to support incidents. Incident-specific events are linked to a support incident at all times in project workflow. To define the scope of an event template and the applicable event scope of all events based on that event template, select an option from the Event Scope dropdown list. If the General Event Templates option is selected, the event template may be used to create general events only. If the Incident-specific Event Templates option is selected, the event template may be used to create incident-specific events only. If the The Both Incident-specific and General Event Templates option is selected, the event template may be used to create both general events and incident-specific events Defining the Prefix and Help Notes Project administrators may define help notes that are added when an event is submitted to a project and an event name prefix that identifies events in the Properties page. The Help Note The Prefix Defining Event Number Restrictions Single open event select if multiple events of the same event type can be open for an issue at the same time. Checking this option at the bottom of the page prevents more than one event of the same type from being open for each incident. Select if multiple events of the same event type can be open for an opportunity/ incident at the same time. Checking this option at the bottom of the page prevents more than one event of the same type from being open for each incident Defining Event Template Identifiers Project administrators may define an identifying prefix that is appended to events in the Properties page. The Template identifier is used to identify the event template that was used to generate an event. The template identifier is useful when working with events that have been imported from another project Administering Global Event Templates A global event template is an event template that has been defined as applicable to multiple ServiceWise work projects. Project members may use global event templates to create global events in every work project in a ServiceWise site. Using controls in the Property tab of the Event Templates page, project administrators may define a regular event template as a global event template and define all global event settings. Figure 12-2: Global Event Dialog Box Global events may be viewed and tracked in multiple projects simultaneously. The ability of project members to create, view, edit, and delete global events may be restricted based on administrator-defined access rules. All global events are defined by the regular event type. Global event administrative tasks include: Defining Event Templates as Global Event Templates Defining Global Event Template Access Controls Displaying Global Events in Projects Defining Event Templates as Global Event Templates To define an event template as a global event: 1Select an event template in the Event Templates list of the Event Templates page in the Event Template folder. The selected event template must be of the regular event type. Event templates based on other event types may not be defined as global event templates. 2Select the If Global Event check box in the Properties tab Defining Global Event Template Access Controls To define global event template access controls: 1Select a global event template in the Event Templates list of the Event Templates page in the Event Template folder. 2Click the Global Event button. The Global Event dialog box appears. 3Select an account type in the account type tree control. 4Select one or more privileges in the Authority area. Project administrators may grant four different privileges to each account type: the create privilege, edit privilege, delete privilege, and the view privilege. Page 77 of 145

78 To enable the account type to create global events based on the template, select the Can Create check box. To enable the account type to edit global events based on the template, select the Can Edit check box. To enable the account type to delete global events based on the template, select the Can Delete check box. To enable the account type to view global events based on the template, select the Can View check box. 5Click the OK button. The Global Event dialog box closes Displaying Global Events in Projects To display global events in the projects: 1Select a global event template in the Event Templates list of the Event Templates page in the Event Template folder. 2Click the Global Event button. The Global Event dialog box appears. 3Select a project in the account type tree control. 4Select the Show This in Incident View check box. 5Click the OK button. The Global Event dialog box closes Administering Event Submission Access Controls Event submission access controls determine which project members and employees may create events based on an event template Administering Event Editing Access Controls Event editing access controls determine which project members and employees may edit events based on an event template. Note:The Delete Event privilege overrides all view and edit access privileges. Project members that have the privileges to delete events, may view or edit that event as well, regardless of all other settings. To enable project members to edit events: 1Select an event template in the Event Template list of the Event Template page. 2Select an option from the Team dropdown list in the Who Can Edit tab of the Event Templates page. The Based on Account Type Definition option 3 Optional:If the Applicable Support Team May Edit option is selected in the Team dropdown list, select one or more team groups or account types in the Applicable Account Types list control. The Applicable Account Types list control displays the all of the administrator-defined team groups and account types in the project. To enable employees to edit events: 1Select an event template in the Event Template list of the Event Template page. 2Select an option from the Employee dropdown list in the Who Can Edit tab of the Event Templates page. The Employee dropdown list displays four options: The All Employees Can Edit option enables all project members to edit events based on the event template. The Applicable Employees May Edit option enables the project administrator to define which employee types may edit events based on the event template. The Only Power User Employees Can Edit enables Power Users to edit events based on the event template. The No Employee Can Edit restricts employees from editing events based on the event template. 3 Optional:If the Applicable Employees May Edit option is selected in the Employee dropdown list, select one or more employee types in the Applicable Account Types list control. The Applicable Account Types list control displays the all of the administrator-defined employee types in the project Administering Event Deletion Access Controls Event deletion access controls determine which project members and employees may delete events based on an event template. Note:The Delete Event privilege overrides all view and edit access privileges. Project members that have the privileges to delete events, may view or edit that event as well, regardless of all other settings Enabling Employees to Delete Events Project administrators may define which project members and employees may delete events based on administrator-defined event templates in the Who Can Delete page of the Event Template page. Project administrators may choose one of three employee submission options for each administrator-defined event template: All Employees Can Edit Applicable Employee May Edit No Employee Can Edit If the Applicable Employee May Edit option is selected in the Employee dropdown list, the administrator must enable each employee type to delete events based on the selected event template. To enable employees to delete events: 1Select an event template in the Event Template list of the Event Template page. 2Select an option from the Employee dropdown list in the Who Can Delete tab of the Event Templates page. The Employee dropdown list displays four options: The All Employees Can Delete option enables all project members to delete events based on the event template. The Applicable Employees May Delete option enables the project administrator to define which employee types may delete events based on the event template. The Only Power User Employees Can Delete enables Power Users to delete events based on the event template. The No Employee Can Delete restricts employees from deleting events based on the event template. 3If the Applicable Employees May Delete option was selected in the Employee dropdown list, select one or more options in the Applicable Account Types list control. The Applicable Account Types list control displays the all of the administrator-defined employee types in the project Administering Event Attachment Rules Project administrators may define which types of attachments may be associated with events and how TechExcel ServiceWise manages those attachments in the Attachment page of the Event Template page. Page 78 of 145

79 Figure 12-3: Attachment Tab in the Event Template Page The Attachment tab is not displayed if an knowledge management event template is selected Managing Applicable Attachment Types Event attachment rules define if files may be attached to events in ServiceWise projects, which and Using controls in the Attachment tab of the Event Templates page, project administrators may enable (or require) project team members to add file attachments to ServiceWise events and define which types of files may be attached to events on a template-by-template basis. If attachments are enabled for an event-template, two types of files may be attached to events based on that template.: Documents based on Document Templates:Document attachments may be restricted to files that are based on predefined document template. New Documents: New document (not from document template) allows team members and customers to attach any file from their local computer to the event. If not selected, only document template files can be attached Defining Form-Based Event State Automation Form-based event state workflow automation rules enable project administrators to ensure that the workflow state of an event is automatically defined whenever a FormWise form is submitted to the project. In ServiceWise, access to forms is based on event state. By automatically defining state of an event based on the submission of a form, project administrator may better control access to form data. To define event state based on form submission: 1Select an event template in the Event Template page of the Event Management folder. 2Select the Attachment tab. 3Select an event state in the Event State After Form Submission dropdown list. The Event State After Form Submission dropdown list displays all administrator-defined event states for the selected event template and the{no Change} workflow variable Managing Regular Event Templates Regular events enable support organizations to track daily activities, such as online demos or calls to employees. Project administrators may create as many different event templates of the regular event type as are needed to manage regular tasks in their projects. The Regular Event event type represents a set of business rules for managing regular events. The ServiceWise sample project features nine different event templates based on the regular event type. Project administrators may consider creating event templates for common tasks. Attachment event template Call Employee event template Call ServiceWise event template Employee Called event template Equipment Request event template Manager Approval Request event template Office Visit event template Online Meeting event template Site Visit event template Creating Regular Event Templates To create and define regular event templates: 1Click the New button in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears. 2Define a unique descriptive name for the event template in the Name text edit box control. The Name property identifies the unique name of the event template. The event template name is the default name for all userdefined events that are based on the selected event template. 3Enter a brief description of the event template in the Description text edit box control. Page 79 of 145

80 The Description property provides a brief description of the workflow rules represented by the event template. The event template description is the default description for user-defined events that are based on the selected event template. 4Select the regular event type option the Event Type dropdown list control. 5Click the OK button. The Add a New Event Template dialog box closes Defining Closed Date Controls In ServiceWise, project members may track the time and date that an event was closed in the Closed Date control. The Closed Date control is a read-only control that displays the time and date that an event was closed. The Closed Date control is only displayed in the ServiceWise client or Employee Web Portal if it has been defined as Visible in the event template Defining Elapsed Time Controls In ServiceWise, project members may track the time and date that an event was closed in the Elapsed Time control. The Elapsed Time control is a read-only control that displays the time that has elapsed between the creation and closure of the event. The Elapsed Time control is only displayed in the ServiceWise client or Employee Web Portal if it has been defined as Visible in the event template Defining Event Template Scope The event scope determines whether the event template may be used to create general events, incident-specific events, or both general events and incident-specific events Managing Asset Operation Event Type Event Templates The Asset Operation event type represents a set of business rules for managing asset operation events. Every event template based on the Asset Operation event type is applicable to one of ten types of assets. Asset operations are events that represent asset management tasks. Project members may use asset operation events to create, manage, and track the asset management tasks that must be completed to close a ServiceWise incident. Asset Operation event templates may be based on eight different asset operation types. {Assign Asset} {Associate} {Disassociate} {New Asset} New Employee Assets {Return Asset} {Update Status} {Upgrade} Creating Asset Operation Event Templates Project administrators may create multiple event templates based on the Asset Operation event type. Project members may use asset operation event templates to create asset operation events in the ServiceWise clients. To create an asset operation event template: 1Click the New button in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears. 2Define a unique descriptive name for the event template in the Name text edit box control. The Name property identifies the unique name of the event template. The event template name is the default name for all userdefined events that are based on the selected event template. 3Enter a brief description of the event template in the Description text edit box control. The Description property provides a brief description of the workflow rules represented by the event template. The event template description is the default description for user-defined events that are based on the selected event template. 4Select the Asset Operation Event Type option from the Event Type dropdown list control. 5Select an asset operation from the Asset Operation dropdown list. The Asset Operation dropdown list displays eight different event type options: {Assign Asset} {Associate} {Disassociate} {{New Asset} New Employee Assets {Return Asset} {Update Status} {Upgrade} 6Click the OK button. The Add a New Event Template dialog box closes. 7Define event submission access controls in the Submitters tab of the Event Templates page. 8Define event editing access controls in the Who Can Edit tab of the Event Templates page. 9Define event deletion access controls in the Who Can Delete tab of the Event Templates page. 10Define event attachment rules in the Attachments tab of the Event Templates page Defining Asset Operations The Asset Operation property defines an applicable asset operation for the event template. The Asset Operation property is only applicable to asset operation events. Applicable assets include: {Assign Asset} {Exchange} {New Asset} {{Parts} {Reconcile} Page 80 of 145

81 {Return Asset} {RMA Return with Exchange} {RMA Return} {Update Status} {Upgrade} The Asset Operation dropdown list is only displayed in the Properties page if the event template is defined as an asset operation event in the Event Type dropdown list Defining Applicable Assets Project administrators may associate one or more assets with an event template by selecting applicable assets in the Product list displayed in the Applicable Assets tab. The Product list displays high-level information about the products managed in the project including the product name, category, and category ID number. An asset is only applicable to the Asset Operation event template when a check mark appears next to the name of the product in the Product list Defining Event Template Applicable Asset Rules Project administrators may define price schedules and applicable products for Asset Operation event templates in the Attachment page of the Event Template page. Figure 12-4: Applicable Asset Tab in the Event Template Page The applicable asset rules that the administrator defines for the Asset Operation event template are inherited by all Asset Operation events created in the client based on that event template. The Applicable Asset tab consists of two controls: The Price Schedule dropdown list displays every price schedule defined in the current project. The Product list displays high-level information about the products managed in the project including the product name, category, and category ID number. The Applicable Asset tab is only displayed in the Properties page if an Asset Operation event template is selected in the Event Template list Defining Price Schedules Project administrators may define the price schedule used for assets associated with an event template by selecting a price schedule from the Price Schedule dropdown list. The Price Schedule dropdown list displays every price schedule defined in the current project. Typical price schedules include: Educational Pricing Enterprise Pricing Government Pricing Small Business Pricing Standard Pricing Managing Autodiscovery Asset Event Templates Project administrators may create multiple event templates based on the Auto Discovered Asset event type. Project members may use asset autodiscovery management event templates to create asset autodiscovery events in the ServiceWise clients. Asset autodiscovery events represent the autodiscovery events. Project members may use asset autodiscovery events to identify assets Understanding Asset Autodiscovery Event Asset Operations Asset autodiscovery event asset operations The {Chat} asset operation {Detail Info} asset operation {File Transfer} asset operation {Remote Control} asset operation {Remote Execute} asset operation Creating Asset Autodiscovery Event Templates Project administrators may create asset autodiscovery event templates in the in the Event Templates page of the Event Management folder or the Event Template Setting page of the Asset Autodetection Integration folder in the Asset Management AssetWise folder. Page 81 of 145

82 Figure 12-5: Event Template Setting Page in the Asset Autodetection Integration Folder To create autodiscovery event templates: 1 Click the New button in the Event Template Setting page of the Asset Autodetection Integration folder in the Asset Management AssetWise folder. All other event templates are created in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears. 2 Define a unique descriptive name for the event template in the Name text edit box control. The Name property identifies the unique name of the event template. The event template name is the default name for all userdefined events that are based on the selected event template. 3 Enter a brief description of the event template in the Description text edit box control. The Description property provides a brief description of the purpose and functionality of the event template. The event template description is the default description for user-defined events that are based on the selected event template. 4 Select the Asset Autodiscovery Asset Event option from the Event Type dropdown list control. In the Event Template Setting page of the Asset Autodetection Integration folder on the Asset Autodiscovery Asset Event option is displayed. 5 Select an asset operation: The {Chat} asset operation {Detail Info} asset operation {File Transfer} asset operation {Remote Control} asset operation {Remote Execute} asset operation 6 Click the Submit button Managing Announcement Event Templates Project administrators may create multiple event templates based on the Knowledge Management event type. Project members may use knowledge management event templates to create knowledge management events in the ServiceWise clients. Knowledge management events represent knowledge management tasks. Project members may use knowledge management events to create, manage, and track the knowledge management tasks that must be completed to close a ServiceWise incident Enabling Automatic Event Status Definition Project administrators may enable the status of announcement events to be automatically defined whenever an is sent. The Auto Set Status to when All s Are Send dropdown in the Properties page displays the states. The option selected is defined as the default state for all default options. Auto set statuses may be used to automatically close events after the all has been delivered. The Auto Set Event Status To When All s Are Sent dropdown list is only displayed in the Properties page if the event template is defined as a announcement event in the Event Type dropdown list. The Announcement event type represents a set of business rules for managing announcement events Creating Sent Announcement Templates To create and define announcement event templates: 1 Click the New button in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears. 2 Define a unique descriptive name for the event template in the Name text edit box control. The Name property identifies the unique name of the event template. The event template name is the default name for all userdefined events that are based on the selected event template. 3 Enter a brief description of the event template in the Description text edit box control. The Description property provides a brief description of the workflow rules represented by the event template. The event template description is the default description for user-defined events that are based on the selected event template. 4 Select the announcement event type option the Event Type dropdown list control. 5 Click the OK button. The Add a New Event Template dialog box closes. 6 Define event submission access controls in the Submitters tab of the Event Templates page. 7 Define event editing access controls in the Who Can Edit tab of the Event Templates page. 8 Define event deletion access controls in the Who Can Delete tab of the Event Templates page. 9 Define event attachment rules in the Attachments tab of the Event Templates page Managing Received Event Templates The Received event type represents a set of business rules for managing received events. An received event based on an received event template is created automatically in a ServiceWise project whenever an employee sends an to the support team. Page 82 of 145

83 Project administrators may create multiple event templates based on the Received event type in the Event Templates page of the Event Management folder in the ServiceWise Admin client. received event templates are crucial to ServiceWise project workflow and event tracking. Every received by the ServiceWise retrieval service is represented and tracked in the ServiceWise project as an event. All retrieval events are created from event template that are based on the Retrieval event type. A project administrator must define at least one received event in every ServiceWise project for the ServiceWise integration features to function properly. Every administrator-defined team address is assigned a default received event template and a default sent event template. sent to or sent from that address automatically generate an event based on the corresponding event template. Project administrators may multiple received event templates only if they have enable advanced settings in the project and defined a single team address. For more information see See Defining Team Accounts Creating Received Event Templates To create and define received event templates: 1Click the New button in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears. 2Define a unique descriptive name for the event template in the Name text edit box control. The Name property identifies the unique name of the event template. The event template name is the default name for all userdefined events that are based on the selected event template. Chapter 13 Employee Administration 13 Chapter13 -- Employee Administration This chapter provides a broad overview of ServiceWise employee management, and ServiceWise employee administrative tasks. All TechExcel employee management processes are performed in the Employee view of ServiceWise clients using administrator-defined tools, business objects, and business rules. In this chapter: Understanding Employee Management Administering Employee View Customization Administering Common Addresses Managing Employee Types Administering Employee Management Access Controls Administering Quick Web Links Administering the Company Hierarchy 13.1 Understanding Employee Management TechExcel ServiceWise provides businesses with powerful internal service and support solutions that enable them to effectively manage and automate their service desk processes. As aninternalservice and support solution, ServiceWise is designed to enable company support engineers ServiceWise project members to manage support requests from company employees, associates, and partners. Employee accounts represent the company employees for whom ServiceWise support engineers create, manage, and track incidents and events in a ServiceWise project. Employee accounts may be identified by their employee type, job function, site, division, department, and group. All employees may be tracked and managed by project members in the Employee view of the ServiceWise clients. TechExcel ServiceWise enables project administrators to define businesses objects, processes, and workflow rules that enable ServiceWise work project members to manage employees effectively. TechExcel enables businesses to manage employees through every step of the employee life cycle. TechExcel ServiceWise automates all employee-related processes and enables project members to view the complete history of employee interactions. TechExcel ServiceWise business and workflow rules ensure that employees are effectively managed and seamlessly transition between ServiceWise project members. TechExcel ServiceWise provides businesses with tools for analyzing employee needs and behavior. TechExcel ServiceWise enables project members to effectively communicate and collaborate with employees by phone, , and web conversations Understanding Employee Administration All ServiceWise work projects share a commonbase projectthat enables project teams to share a common database of employees. Configurations and customizations made in a ServiceWise base project are passed on to every work project in the ServiceWise site. All employee and employee data is stored in a employee base projects and tracked in the child work projects through the Employee view. ServiceWise employee administration falls into four broad categories: Employee view customization Employee support automation administration Employee Web Portal administration Web form administration Employee view customization Employee view administrative tasks are performed using tools in the Employee View folder of the ServiceWise Admin client. Employee view administrative tasks include: Defining employee properties and customizing the Employee view to support employee management processes. Enabling project members to define employees. Defining the domain of common addresses and define default settings for from that domain Defining employee types and employee type access controls. Managing power users. Defining the company hierarchy. Defining employee autoassignment rules. Defining Quick Web Links in the Employee view Administering Employee View Customization In ServiceWise, the Employee view provides project members with the tools they need to create, manage, and track employees in the ServiceWise Windows client and ServiceWise Web clients. Page 83 of 145

84 Figure 13-1: Employee View in the ServiceWise Windows Client The Employee view consists of two windows: the Employee list window and the Employee Detail window. The Employee list window displays high-level information about multiple employees in a tabular format. The Employee detail window displays detailed information about a single employee in multiple tabbed pages: the Employee page, the Team page, the Incidents and Events, and up to two custom pages. Employee view administration, configuration, and workflow settings are defined at the base-project level. In ServiceWise, all employee data is stored in a base project and tracked in child work projects through the Employee view. The same Employee view is displayed in every ServiceWise project that shares the same base project. Project administrators may define employee management options, define project member access controls, and customize the graphical user interface of the Employee view to support and manage the employee data in the Employee View folder in the Admin tree window of base and work projects. Employee view administration tasks include: Defining Employee View Terminology Defining Employee Dropdown List Size Limits Enabling Support for Login Aliases Customizing the Employee View Employee Page Customizing the Employee View Team Page Customizing the Employee View Incidents/Events Page Customizing Employee View Custom Pages Defining Employee View Terminology The Employee view enables project members to create, manage, and trackemployeesin the ServiceWise Windows and ServiceWise Web clients. Project administrators may define employees and customize the graphical user interface that is used to track those employees in the ServiceWise implementation. By default, the termemployeeis used to refer to company employees in ServiceWise projects, but a business may use any term that appropriate to their industry or business model. For example, a business may wish to refer to employees as anassociates, orpartners, or by another name that is better suited to their business or more intuitive for their support engineers. To define a custom term for project employees, enter the term in the Refer Employee As field of the General Settings page. Once the new term is defined the wordemployeeis replaced by that term globally throughout the ServiceWise site Defining Employee Dropdown List Size Limits Project administrators may limit the number of employees that are displayed in the Employee dropdown lists in the Incident, Event, and Report views using controls in the General Setting page. Limiting the number of employees displayed in the Employee dropdown list may enhance the performance of the ServiceWise client applications. Businesses may maintain a employee base that includes thousands of employees, and loading all of their employees into the dropdown list in each view can deteriorate application performance. To limit the number of employees loaded into the Employee dropdown list, enter a number in the Size Limit of the Employee Dropdown List text field in the General Setting page Enabling Support for Login Aliases The Employee Web Portal is a secure, interactive web site that provides employees with controlled access to a centralized communication hub. Employee Web Portal enables employees to track their incidents, communicate with support engineers, and view or update their personal data. To access the Employee Web Portal, an employee must log in using a unique login name and password. By default, the login name for each employee is the address recorded for that employee in the base project. Project administrators may optionally enable support for login aliases in ServiceWise sites. An employee login alias is a login name that is specifically created for an employee by a ServiceWise project member in the ServiceWise client. Once defined, the employee must use their login alias and password to access the Employee Web Portal. To enable support for login aliases, select the Support Login Alias check box in the General Setting page of the Employee View folder in the ServiceWise Admin client Customizing the Employee View Employee Page The Employee page is displayed in the Employee detail window of the ServiceWise clients and enables project members to record and track detail information about company employees. Project administrators may determine the kinds of employee data that is recorded and tracked in ServiceWise projects by customizing the data-entry controls displayed in the Employee page. The Employee page consists of 23 different system-defined controls. Every control displayed in the Employee page, including the page title, may customized. The table refers to Employee Info controls by the default control title. All controls may be renamed by the project administrator. Page 84 of 145

85 Table 13-1: Employee Page Customizations The table refers to Employee page controls by the default control title. All controls may be renamed by the project administrator. A blank field indicates that the option is not applicable to the control. AnXindicates that the option may be enabled for the control. A gray field indicates that the option is enabled for the control andcannotbe disabled. Project administrators may make the following customizations to data-entry controls displayed in the Employee page: Field Name: Project administrators may customize the name of every data-entry control displayed in the Employee page. Visible: Project administrators may define many data-entry controls as either visible or invisible in the Employee page. The Company Name, Address, Employee ID, City, Zip, and Main Phone controls are always visible. Project administratorsmay notdefine these controls as invisible in the Employee page. All other controls may be defined as visible or invisible. Available in Employee Web Portal: Project administrators may choose whether controls are displayed or not displayed in the Employee Web Portal. The Company Name control isalways displayed in the Employee Web Portal. All other controls may or may not be displayed. Mandatory for Team: Project administrators may define Address controls as mandatory fields for project members. Mandatory for Employee: Project administrators may define Address controls as mandatory fields for employees. Mandatory on Submission: Project administrators may define Address controls as mandatory fields whenever an incident is submitted Customizing the Employee View Team Page The Team page is displayed in the Employee detail window of the ServiceWise clients and enables project members to assign employees to a system team group and to assign primary and secondary support engineers to employees. The Team page displays three data-entry controls: The Group Assigned To control, the Primary Support Engineer control, and the Secondary Support Engineer control. A primary support engineer is a project member that is designated as the support engineer primarily responsible for the support incidents belonging to an employee. A secondary support engineer is a project member that is designated as the support engineer that is secondarily responsible for the support incidents belonging to an employee. To customize the Group Assigned To control: The Group Assigned To control in the Team page enables project members to assign an employee to an administrator-defined system team group. A system team group is a administrator-defined group of ServiceWise users that represents the internal structure of the company. All system team groups are defined by a system administrator and are shared by every work project in a ServiceWise implementation. For more information see See Administering System Team Groups on page 14. Project administrators may enable or retitle the Group Assigned To control using controls in the Team page in the Employee folder of the ServiceWise Admin client. To customize the Primary Support Engineer control: ThePrimary Support Engineer controlenables project members to designate a support engineer to a employee. Project administrators may ensure that only support engineers that belong to the selected system team group are displayed in the Primary Support Engineer dropdown list From Assigned Group Only check box. Project administrators may choose to make this control visible or invisible in the Team page. To customize the Primary Support Engineer control: TheSecondary Support Engineer control enables project members to designate a support engineer to a employee. Project administrators may ensure that only support engineers that belong to the selected system team group are displayed in the Primary Support Engineer dropdown list From Assigned Group Only check box. Project administrators may choose to make this control visible or invisible in the Team page Customizing the Employee View Incidents/Events Page The Incidents/Events page is displayed in the Employee detail window of the ServiceWise clients and enables project members to track the open incidents and events that belong to a specific employee. To enable the Incidents/Events page to be displayed in the Employee view of the ServiceWise clients, select the Show this Page check box in the Incidents /Events page of the Page 85 of 145

86 Employee View folder in the ServiceWise Admin client. To enable the Incidents/ Events page to displayed data from other projects in the ServiceWise clients, select the Support Data Access of other Projects check box in the Incidents and Events page of the Employee View folder in the ServiceWise Admin client and select one or more project in the list. A red check mark is appears next to the applicable projects Customizing Employee View Custom Pages Project administrators may customize two custom pages (Custom Page 1 and Custom Page 2) in the Employee view, adding up twelve fully customizable fields into each custom page. Project administrators may customize custom pages by adding up to twelve different controls to each custom page. The Add Control manager enables project administrators to add five different control types and to define the name of employee controls. Every custom page enabled by a project administrator may be shared across all work projects in the ServiceWise implementation. Project administrators may choose to hide custom pages, share custom pages across projects, or display in one work project only. To hide the custom page: 1Click the Setup button. The Setup dialog box appears. 2Select the Do Not Show this Page option. 3Click the OK button. To display the custom page in current project only: 1Click the Setup button. The Setup dialog box appears. 2Select the Show This Page and the Settings/Data are Specific to the Current Work Project option. 3 Optional:To copy settings from the base project to the current project, select the Copy Settings/Data from the Base Project to the Current Project button. The Copy Data dialog box appears. 4Select an option: Copy Setting only Copy Data only Copy Setting and Data 5Click the OK button.interproject To hide custom pages: 1Click the Setup button. 2The Setup dialog box appears. 3Select the Show This Page and the Settings/Data are Common to the Base Project option. 4 Optional:To copy settings from the current project to the base project, select the Copy Settings/Data from the Current Project to the Base Project button. The Copy Data dialog box appears. 5Select an option: Copy Setting only Copy Data only Copy Setting and Data 6Click the OK button Administering Common Addresses Businesses may prefer not to allow employees to register using anonymous accounts, such ashotmail.com or yahoo.com. Project administrators may restrict the addresses that employees may to create a new account on the Employee Web Portal using controls in the Common page of the Employee View folder. Figure 13-2: Edit Property Manager To restrict addresses: 1Click the Common page in the Employee View folder. 2Click the New button. The Edit Property manager appears. 3Define the name. 4Define the domain. domains in the group must be separated by a comma. 5 Optional:To disable the as a matching criteria, select the Do Not Use Such Address as a Criteria to Match Existing Company check box. If this option is selected, from the selected domain names are not used to match employees with pre-existing company data. 6 Optional:To restrict employee self-regulation, select the Do Not Allow Employee Self-registration with such check box. Employees from the selected domain may not register. 7Define a note that is displayed to employees. Project administrators may customize a message to be displayed to employees registering with s from any of the selected domain names. The address specified in not allowed for self registration. Please enter your company address. 8Define the default employee status. Defines the default employee status for employees registering with s from any of the selected domain names. 9Define the default employee type. Defines the default employee type for employees registering with s from any of the selected domain names. 10Define the default employee type. Defines the default employee type for employees registering with s from any of the selected domain names Managing Employee Types In ServiceWise base project, every employee is assigned an administrator-defined employee type that defines the privileges that are granted to that employee in all child work projects. Page 86 of 145

87 ServiceWise uses employee types to define project-level security and access controls and to coordinate employees in project workflow. An employee type represents the role that an employee has in a company and determines the actions the tasks that the employee may perform in the Employee Web Portal. Employee access to ServiceWise projects through the Employee Web Portal and the ability of those employees submit, edit, or view incidents is based on the administratordefined employee type assigned to them in the ServiceWise project. Every employee type may be granted two types of access controls: work project access controls and base project access controls: Work project access controls enable employees to submit, edit, and manage incidents. Employee types may be assigned a different set of access controls in each work project. Base project access controls enable employees to register in the Employee Web Portal, search the knowledge base, view reports, and create and edit employee and employee data. Employee type management tasks include: Creating Employee Types Defining Employee Type Access Controls Understanding Power Users Defining Employee Applicable Projects Creating Employee Types Anemployee typerepresents the role that is played by an employee in a business and are used in ServiceWise to implement project-level security and to coordinate employees in project workflow. An unlimited number of employee types may be created to represent the different types of employees that are served by a support organization. Each employee type may represent a unique set of base project and work project privileges and workflow rules. All employee types are created and defined in the Employee page of the Employee View folder in the ServiceWise Admin client. To create an employee type: 1Double-click the Employee Type control in the Employee page of the Employee View folder in the ServiceWise Admin client. The Setup UI Fields dropdown list appears. 2Click the Setup button. The Employee Type Setup manager appears. 3Click the New button. The New Type Name dialog box appears. 4Define a unique name for the employee type in the Name edit box control 5Click the OK button. The employee type is displayed in the Employee Type list Defining Employee Type Access Controls Every administrator-defined employee type may be granted a unique set of base project and work project privileges. In ServiceWise, project security is implemented using projectlevel access controls. Employee type access controls define the ability of an employee to access and manage their support incidents and account settings in a project. Project administrators may grant base project and work project-specific access controls to administrator-defined employee types in the Employee Type Setup manager in the ServiceWise Admin client. Figure 13-3: Employee Type Setup Manager Project administrators may grant four access controls to the employee type that are applicable in the current project including the ability to submit and edit incidents, view incidents belonging to other employees, and edit their own incidents, and the ability to edit other employee s web conversations Employee types and power users Project administrators may choose to assign power user access controls to an employee type by selecting the Is Power User check box in the Employee Setup manager. In TechExcel ServiceWise, a power user is an employee that has been granted special access controls that enable that employee to submit, view and edit incidents and events that belong to other employees. For each employee type that is granted power user status, the administrator must define a scope for the power user access controls granted that employee type. Power user access controls may be restricted to an employee s group, department, division, or site. To define employee type access controls: 1Select an employee type in the Employee Types list of the Employee Type Setup manager. 2Select the Privileges tab. 3 Optional: To define the employee type as a power user, select the Power User check box. 4 Optional: To define the scope of the power user privileges, select an option from the Scope dropdown list. The Scope dropdown list displays four options representing the different levels in the company hierarchy: All Site Division Department Group Note:The Scope dropdown list is displayed only if the Power User check box is selected. 5Select an incident submission access controls for the employee type in the Incident Submission dropdown list. Project administrators may restrict the ability of an employee type to submit incidents or ensure that all incidents are based on user-defined incident templates. The Incident Submission dropdown list displays three options: Cannot Submit New Incident Can Submit with or without Incident Template Can Submit with Incident Templates Only 6 Optional: To grant additional employee work project-specific access controls to the employee type, select one or more options in the Work Project Specific Privileges area of the Privileges tab. Can Edit Own Incidents Can View Others Incidents Can Edit Web Conversations for Others Incidents Page 87 of 145

88 7 Optional: To grant employee base project-specific access controls to the employee type, select one or more options in the Base Project Specific Privileges area of the Privileges tab. Available to Employees for Self Assigning Can Search Knowledge Base Can View Reports Can Edit Employee Contact Employee Type Can Edit Own User Info Can Edit Own Login Info Can Assign Company Hierarchy Can Edit Address Info 8Select the OK button Understanding Employee Type Base Project Access Controls Employee base project-specific access controls are access controls that are valid in every work project in a ServiceWise implementation. Generally, employee base project access controls enable employees belonging to the appropriate employee type to access data in the Employee Web Portal and manage employee data. Table 13-2: Employee Base Project-Specific Access Controls Understanding Employee Type Work Project Access Controls Work project access controls enable employees to submit, edit, and manage incidents in a single ServiceWise project. Employee types may be assigned a different set of project-specific access controls in each work project. Each employee type may be granted assigned four project-specific access controls.: a incident submission privilege, two incident editing access controls and a web conversation editing privilege. Page 88 of 145

89 Table 13-3: Employee Work Project-Specific Access Controls Understanding Power Users In TechExcel ServiceWise, apower user is an employee that has been granted special access controls that enable that employee to submit, view and edit incidents and events that belong to other employees and to create events based on a power user event template. Project members are designated power users based on theiremployee type.all employees are assigned an employee type that represents a set of base project-specific and work project-specific access controls: the ability to submit, view and edit incidents and events depend on the employee type assigned to an employee. Project administrators may create employee types that are entitled to perform power user tasks. Project members assigned an employee type that has been granted power user access controls are deemed to be power users. Power users are special employees who may submit, view, and edit incidents and events that belong to other employees. Power users are assigned a scope based on their employee type. The scope of their power user access controls may be restricted to an employee s group, department, division, or site. (global, site, plant, department, group) which determines which incidents and events they may access in a project. Power users may ownpower user events.power user events are events based on an event template of the power user event type Defining Employee Applicable Projects Project administrators may define which projects are accessible to employees based on the employee type assigned to them in the Employee Type Setup manager in the ServiceWise Admin client. To define employee applicable projects: 1Select an employee type in the Employee Types list of the Employee Type Setup manager. 2Select the Applicable Projects tab. 3Double-click a project. The Set Property dialog box appears. 4 Optional: To define the project as applicable, select the If Applicable check box. If the Applicable option is enabled the employee type may access and work on the work project. 5 Optional: To define the employee type as auto-created, select the If Auto Create check box. 6Click the OK button Administering Employee Management Access Controls Project administrators may grant page and field-level access controls to project members and employees that enable them to define employee account properties whenever they create a new employee or update existing employee data. The Employee page and Team page are displayed in both the Employee detail window of the ServiceWise clients and the Employee Web Portal. Project members and employees that have been granted the appropriate access controls may use the data-entry controls displayed in these pages to manage employee accounts. Project administrators may define pages and data-entry controls as editable, invisible, or read-only based on the account type of the project member or the employee type of the employee. Account types are defined in the Account Type page of the General Project Setting folder. Employee types may be defined in the Employee Type Setup manager in the Employee system page of the ServiceWise Admin client. The Field Access page is divided into three main areas: the Account Type list, the On Creating New Employee tab and the On Existing employee tab. The Types list displays all of the account types and employee types created in the project. Project administrators may grant a unique set of access controls to each account type and employee type. The On Creating New Employee tab enables the administrator to grant field-level access controls to project members and employees when they create new employees. All field-level access controls are granted to account types. The On Existing Employee tab enables the administrator to grant field-level access controls to project members and employees when they update existing employees. All field-level access controls are granted to account types Defining Project Member Access Controls Project administrators may define access control access controls for the Employee page and Team page in the Access Control page of the Employee View folder. Project administrators may define pages and data-entry controls as editable, invisible, or read-only based on the account type of the project member. Project administrators may grant a different set of access controls to project members based on whether they are creating a new employee or updating and existing employee. To define access control access controls for project members: 1Select the Enable Field Access Control for Team check box in the Access Control page of the Employee view folder. The Enable Field Access Control must be selected for the Page Level Access and Field Level Access controls to be editable. 2Select an account type in the Types list. The Types list displays all of the account types (project members) and employee types (employees) defined in the project. 3Select the On Creating New Employee tab. The On Creating New Employee tab is divided into two areas: the Page Level Access area and the Field Level Access area. The Page Level Access area displays two pages: the Employee page and the Team page. The Field Level Access area displays the data-entry controls displayed in the Employee page or the Team page. 4Define the page-level access controls for the Employee page and the Team page. Project administrators may choose between two options: The Editable option defines every data-entry control in the page as editable when a project member creates a new employee. The Field Level option enables the administrator to define the access control access controls separately for each data-entry control displayed in the page. 5Define field-level access controls in the Employee page and the Team page. If the Field Level option was selected for either the Employee page or the Team page, define field-level access controls for each of the data-entry controls displayed in that Page 89 of 145

90 page. Project administrators may choose between three options: Invisible Read-only Editable 6Select the On Existing Employee tab. The On Existing Employee tab is divided into two areas: the Page Level Access area and the Field Level Access area. The Page Level Access area displays two pages: the Employee page and the Team page. The Field Level Access area displays the data-entry controls displayed in the Employee page or the Team page. 7Define the page-level access controls for the Employee page and the Team page. Project administrators may choose between two options: The Editable option defines every data-entry control in the page as editable when a project member edits an existing employee. The Field Level option enables the administrator to define the access control access controls separately for each data-entry control displayed in the page. 8Define field-level access controls in the Employee page and the Team page. If the Field Level option was selected for either the Employee page or the Team page, define field-level access controls for each of the data-entry controls displayed in that page. Project administrators may choose between three options: Invisible Read-only Editable Defining Employee Page and Team Page Access Controls Project administrators may define access control access controls for the Employee page and Team page in the Access Control page of the Employee View folder. Project administrators may define pages and data-entry controls as editable, invisible, or read-only based on the employee type of the employee. Project administrators may grant a different set of access controls to employees based on whether they are creating a new employee or updating and existing employee. To define access control access controls for employees: 1Select the Enable Field Access Control for Team check box in the Access Control page of the Employee view folder. The Enable Field Access Control must be selected for the Page Level Access and Field Level Access controls to be editable. 2Select an employee type in Chapter 14 Employee Web Portal Administration 14 Chapter14 -- Employee Web Portal Administration In this chapter: Understanding the Employee Web Portal Defining General Employee Web Portal Settings Managing Employee File Attachments Managing Registration Controls Managing Web Themes Managing Employee Web Portal Field Access Controls Managing Page Style Customization Administering Employee Web Portal Login Controls Customizing the Knowledge Portal Managing Employee Web Portal Reports Defining Single Sign-on Access 14.1 Understanding the Employee Web Portal The TechExcel Employee Web Portal is a secure, interactive Web site providing controlled access to a centralized communication hub and to support processes. The Employee Web Portal enables employees to submit and edit incidents through the Internet. The Employee Web Portal enables employees to view their incidents and events. The Employee Web Portal enables employees to access FAQs, upgrades and patch info, product documentation. The Employee Web Portal enables employees to search the knowledge base, download documents or software, and read whatever news or announcements administrators have determined they should see based on their role. The Employee Web Portal enables employees to conduct Web conversations with ServiceWise project members. Figure 14-1: Incident List Report in the Employee Web Portal The Employee Web Portal is composed of six views. Each Employee Web Portal view displays tools that enable employees to manage incidents, view reports, interact with ServiceWise personnel, or customize their personal information or preferences. The Home view The Incident List view The Submit New view The Employee Info view The Knowledge view The Report view Whenever problems do arise, employees may easily search the knowledge base for information that is specific to their particular incident saving time and reducing overall support costs. The Employee Web Portal enables employees to access helpful hints, upgrades, patch info or any other information an administrator believes is relevant based on their employee type or products purchased. The Employee Web Portal is an optional feature in TechExcel ServiceWise. Support for the Employee Web Portal must be enabled independently in each ServiceWise work project. For more information see See Enabling the Employee Web Portal on page Understanding Employee Web Portal Administration Project administrators may customize the Employee Web Portal using controls in the Employee Web Portal folder of the ServiceWise Admin client. Project administrators may configure and customize the Employee Web Portal using tools in the Employee Web Portal folder of the ServiceWise Admin client. Page 90 of 145

91 Employee Web Portal administrative tasks include: Defining General Employee Web Portal Settings Managing Registration Controls Managing Web Themes Managing Employee Web Portal Field Access Controls Managing Page Style Customization Administering Employee Web Portal Login Controls Customizing the Knowledge Portal Managing Employee Web Portal Reports Defining Single Sign-on Access Employee Web Portal access and security Project administrators may restrict access to projects through the Employee Web Portal based on administrator-defined employee and contact accounts. Project administrators may configure the Employee Web Portal so that only appropriate incidents and incident data are displayed to employees based on their employee type, employee status, and business type,. or the access privileges granted to a employee contact. All employee and employee contact privileges are assigned by project members in the Employee view of ServiceWise projects. Project administrators may define employee types and contact types, assign access privileges to those employee types and contact types, and perform other administrative tasks using tools in the Employee Web Portal folder Employee Web Portal GUI customization Project administrators may completely customize the Employee Web Portal so that its appearance is consistent with their corporate Web site. Company logos, images, background colors, foreground images, and fonts are all fully customizable Understanding Employee Web Portal and Project Types Project administrators may enable and configure the Employee Web Portal for each ServiceWise work project. Employee access to a support project using the Employee Web Portal is the most typical implementation. Employees must pass the associated runtime key for that project in the URL to access each work project Understanding the EWP and the ServiceWise Employee View The Employee view in the ServiceWise clients enables project members to create, manage, and track employees. Employee and contact information is stored in a employee base project.the employee base project enables project teams to share a common database of employees. Each ServiceWise project may be associated with one employee base project. The employee base project is shared by multiple ServiceWise work projects. All ServiceWise work projects share a commonemployee base project. A employee base project enables project teams to share a common database of employees. All employee and employee contact data is stored in a employee base projects and tracked in the child work projects through the Employee view Defining General Employee Web Portal Settings Project administrators may enable the Employee Web Portal, define default work projects, visible projects, and other basic settings in the General Setting page of the Employee Web Portal page. Figure 14-2: General Setting Pages General Employee Web Portal definitions include: Enabling the Employee Web Portal Reloading Web Settings Defining Default Work Projects Defining the Title of the Employee Web Portal Defining Runtime Keys Enabling Incident List Reports Customizing the Employee Web Portal Logos Displaying Multiple Projects to Employees Enabling the Employee Web Portal Project administrators may enable Employee Web Portal support in a work project by selecting the Enable Employee Web Portal check box in the General Settings page of the Employee Web Portal folder. Project administrators must enable the Employee Web Portal for administrator-defined configurations to be implemented Reloading Web Settings Project administrators may reload Employee Web Portal settings by selecting the Reload Web Settings button in the General Settings page of the Employee Web Portal folder. For performance reasons all TechExcel ServiceWise Web settings are cached on the TechExcel ServiceWise Web Server. Whenever an administrators makes any changes in ServiceWise Admin, the administrator must reload the project Web settings to ensure that these changes are visible to users of the Web clients. Note:Clicking the Reload Web Settings button resets the settings for the current project only. If an administrators makes multiple changes across multiple projects, the administrator must reload the Web settings in each project individulally Defining Default Work Projects Thedefault work projectrepresents the default project that employees access when they log into the Employee Web Portal using either the base project runtime key or no runtime key. If a employee logs into the Employee Web Portal and passes a project ID or project runtime key, the employee accesses the associated project and the default project is ignored. Project administrators may define the default work project in the Employee Web Portal by selecting an option from the Default Work Project dropdown list in the General Settings page of the Employee Web Portal folder. Project administrators must define a single work project as the default work project for each base project. The default work project value is stored in the base Page 91 of 145

92 project. For a support project, employees may view, update, and submit support incidents and events Defining the Title of the Employee Web Portal Every Employee Web Portal may display its own unique title to the employees that use that portal to submit and view incidents to a ServiceWise project. To define the title of an Employee Web Portal, enter a unique name in the Web Portal Title text box control in the General Setting page of the Employee Web Portal folder in the ServiceWise Admin client. The title of Employee Web Portals are displayed in the title bar of the employee s web browser Defining Runtime Keys Runtime keys do not replace Web login processes; runtime keys provide an additional level of access control. After passing the appropriate runtime key, user authentication is still required to access a project. TechExcel ServiceWise enables project IDs and runtime keys to be passed as part of the URL. For example, Runtime key configuration is an optional feature.the TechExcel ServiceWise administrator may define a runtime key for each project and restrict access to the project Web login page to a few targeted employees. TechExcel ServiceWise checks to ensure the project ID and runtime key match the information stored in the database. Unauthorized Web users who do not pass the specified project ID and runtime key cannot access the project login page. TechExcel ServiceWise uses three different types of runtime keys. Project administrators also have the option of not defining a runtime key at all: System runtime keys Base project runtime keys Work project runtime keys No runtime key System runtime keys The system runtime key enables employees to access all TechExcel ServiceWise work projects. Key='SystemKey' Employees should not be given the system runtime key because there should be no need to log into all available ServiceWise projects. In this case, all projects must have a project runtime key specified Base project runtime keys Thebase project runtime keyenables employees to directly access the login page for the default work project. Project administrator must define a default project for the Employee Web Portal Work project runtime keys Work project runtime keyswhen used in conjunction with project IDs may enable employees to directly access work project login pages No runtime key If no runtime key is defined, the project ID may still be passed to the URL, and the user may access the work project login page, with no run time key checking (by leaving the runtime key empty in TechExcel ServiceWise Admin). In this configuration, runtime key checking is not required: Enabling Incident List Reports Incident list reports enable employees to quickly view the current status of incidents they have submitted to the ServiceWise through the Employee Web Portal. Figure 14-3: Incident List Report in the Employee Web Portal An incident list reports displays high-level information about multiple incidents in a tabular format. Each row in the list report represents a single incident. Each column in the list report represent an incident property. To enable employees to view incident list reports in the Employee Web Portal, select the Support Incident List Report with Development Status dropdown list in the General Settings page of the Employee Web Portal folder Displaying DevTrack Project Development Issues Support organizations may display the current development status of a linked DevTrack development issues in the Employee Web Portal. Using controls in the Project administrators may define the appropriate development project in the General Settings page of the Customer Web Portal folder, project administrators may identify the integrated DevTrack project. To display the development status of a DevTrack project in the Employee Web Portal, select a development project in the Development Status for Project dropdown list. The Development Status for Project dropdown list displays all DevTrack projects in which the display linked development issue information has been enabled Customizing the Employee Web Portal Logos Project administrators may customize the graphical user interface displayed in the Employee Web Portal to display the logo of their company. The TechExcel ServiceWise logo that is displayed in the upper right hand corner of the browser window may be replaced with another graphic of the same dimensions. The TechExcel ServiceWise logo is namedhelpdesklogo.gif and is stored in beneath the root directory of the web server: C:\Inetpub\wwwroot\SWiseWeb\Images To replace the TechExcel ServiceWise logo with another logo, save the customized logo as a GIF file (120 pixels wide by 25 pixels high) to the image folder. The custom logo must be renamed helpdesklogo.gif_cust.gif. To customize the logo displayed to project members in the ServiceWise Web client, save the custom logo as a GIF file named helpdesklogo.gif.gif to the same directory Displaying Multiple Projects to Employees Page 92 of 145

93 dimensions. The TechExcel ServiceWise logo is namedhelpdesklogo.gif and is stored in beneath the root directory of the web server: C:\Inetpub\wwwroot\SWiseWeb\Images To replace the TechExcel ServiceWise logo with another logo, save the customized logo as a GIF file (120 pixels wide by 25 pixels high) to the image folder. The custom logo must be renamed helpdesklogo.gif_cust.gif. To customize the logo displayed to project members in the ServiceWise Web client, save the custom logo as a GIF file named helpdesklogo.gif.gif to the same directory Displaying Multiple Projects to Employees Companies that manage multiple ServiceWise projects may make each of these projects available to employees through a single Employee Web Portal login page. The Employee Web Portal login page includes the Project dropdown list control which displays one or more work projects that may be accessed through the Employee Web Portal. Figure 14-4: Employee Web Portal Login Page Project administrators may define which work projects are displayed in the Project dropdown list of the Employee Web Portal Login page and the displayed order of those work projects in the General Settings page of the Employee Web Portal folder in the ServiceWise Admin client. Note:If multiple projects are displayed in the Projects dropdown list, employee self-registration cannot be enabled in the Employee Web Portal and the New Employee button is not displayed in the Employee Web Portal login page. To define projects as visible or invisible in the Employee Web Portal: 1Select the General Settings page in the Employee Web Portal folder of the ServiceWise Admin client. 2Define work project as visible or invisible to employees in the Employee Web Portal. To add the work project to the Projects dropdown list displayed in the Employee Web Portal login page, select a work project in the Available Projects list and click the Right arrow. To remove the work project from the Projects dropdown list displayed in the Employee Web Portal login page, select a work project in the Visible Work Projects list and click the Left arrow. 3Click the Reload Web Settings button. To define work project display order in the Project dropdown list: 1Select the General Settings page in the Employee Web Portal folder of the ServiceWise Admin client. 2Select a work project in the Visible Work Projects list. To move the selected work project towards the top of the Project dropdown list, click the Up button. To move the selected work project towards the bottom of the Project dropdown list, click the Down button. 3Click the Reload Web Settings button Managing Employee File Attachments Project administrators may enable employees to attach files to incidents, define file attachment size limits, and restrict the types of files that may be attached to incidents in the Employee Web Portal using controls in the General Setting page of the Employee Web Portal folder in the ServiceWise Admin client. Employee file attachment management tasks include: Enabling File Attachments in the Employee Web Portal Defining Attachment File Size Limits Defining Forbidden File Types Enabling File Attachments in the Employee Web Portal Project administrators may enable employees to attach files to incidents using controls in the General Setting page of the Employee Web Portal folder in the ServiceWise Admin client. To enable employees to attach files to incidents: 1select the Enable Employee to Attach Files to their Incidents check box in the Employee Upload File Via Web area of the General Settings page. 2Click the Reload Web Settings button Defining Attachment File Size Limits Project administrators may restrict the size of the files that employees may attach to incidents using controls in the General Setting page of the Employee Web Portal folder in the ServiceWise Admin client. To define attachment file size limits: 1Enter a number in the File Size Limit control in the Employee Upload File Via Web area of the General Settings page. All file size limits are measured in kilobytes. A value of zero (0) indicates that there is no size limit. 2Enter a brief message in the Warning Message if File Size Exceeds the Limit text box control. The administrator-defined warning message is displayed to employees whenever they attempt to attach oversized files to incidents. 3Click the Reload Web Settings button Defining Forbidden File Types Project administrators may restrict the type of files that employees may attach to incidents and define the warning message that is displayed to employees when they attach oversized files using controls in the General Setting page of the Employee Web Portal folder in the ServiceWise Admin client. To define acceptable file attachment types: 1Select the Prevent Files of Certain File Types from being Uploaded check box in the Employee Upload File Via Web area of the General Settings page. 2Click the Define button. The Define File Types and Warning Message dialog box appears. 3Enter the unacceptable file types in the Excluding the following File Types text box control Unacceptable file types are identified by their three letter extensions. For example,exe, SCR, and BAT. Multiple file types may be separated by a comma. 4Enter a brief warning message in the Warning Message control. The administrator-defined warning message is displayed to employees whenever they attempt to attach forbidden types of files to incidents. 5Click the OK button. The Define File Types and Warning Message dialog box closes. 6Click the Reload Web Settings button Managing Registration Controls The Registration Control subfolder in the Employee Web Portal' folder enables project administrator to define employee login settings. General Employee Web Portal definitions include: Enabling New Employee Self-Registration Enabling Inactive Employees to Log Into the Web Portal Defining New Employee Default Types Defining Registration Methods Enabling New Employee Self-Registration Employee self-registration enables employees to log into the Employee Web Portal, define their login name and password, and other Employee Web Portal settings by clicking the New Employee button in the Employee Web Portal login page. The Employee Self-registration page enables employees to define their login name ( address), password, and personal contact information Page 93 of 145

94 The Employee Self-registration page enables employees to define their login name ( address), password, and personal contact information Figure 14-5: Employee Self-registration Page of the Employee Web Portal Project administrators may enable employees to self-register themselves using controls in the Registration Control subfolder of the Employee Web Portal folder in the ServiceWise Admin client. Project administrators may choose one of four different rules for managing employee self-registration in the Employee Web Portal: The Not Enabled option ensures that the New Employee button is not displayed in the Employee Web Portal login page. The Enabled for All New Employees option enables every new employee to register themselves. The Enabled but for Existing Employees Only based on Internal Employee ID option enables only those employees that are already defined in the ServiceWise base project to self-register. The Enabled but for Existing Employees Only based on Internal and External Employee ID option enables only those employees that are already defined in the ServiceWise base project to self-register. Even if employee self-registration is enabled by a project administrator, the New Employee button may not be displayed in the Employee Web Portal login page. Two other administrator-define settings may prevent the display of the New Employee button and, consequently, the employee self-registration process: If multiple projects are displayed in the Projects dropdown list, employee self-registration cannot be enabled in the Employee Web Portal and the New Employee button is not displayed in the Employee Web Portal login page. To ensure that the New Employee button is not displayed in the Employee Web Portal login page, limit Employee Web Portal access to one work project, or require that employees use runtime keys to access work projects. To enable employee self-registration: 1Select a registration option from the New Employee Self-registration Option dropdown list. The New Employee Self-registration Option dropdown list displays four options: The Not Enabled option The Enabled For All New Employees option The Enabled but for Existing Employees Only based on Internal Employee ID option The Enabled but for Existing Employees Only based on Internal and External Employee ID option 2Click the Reload Web Settings button Enabling Inactive Employees to Log Into the Web Portal To enable inactive employees to log into the Employee Web Portal, and become active immediately, select the Enable Inactive Employee to Login and Become Active Automatically check box in the Registration Control page of the Registration Control subfolder of the Employee Web Portal folder in the ServiceWise Admin client. If the Enable Inactive Employees to Login option is not enabled, inactive employees are shown a message as soon as they complete the self-registration process. The message explains that before they can gain access to the Employee Web Portal, an administrator or company employee must activate their employee account Defining New Employee Default Types Every employee that self-registers in the Employee Web Portal is automatically assigned an employee type. Employee types determine the privileges granted to that employee in the portal. Project administrators may define the default employee type that is assigned to self-registered employees in the Registration Control page of the Registration Control subfolder of the Employee Web Portal folder in the ServiceWise Admin client. To define employee type that is assigned by default to self-registered employees, select an employee type option from the Default Employee Status dropdown list control in the Registration Control page. The Default Employee Status dropdown list displays administrator-defined employee types that are applicable to current ServiceWise project. The Sample ServiceWise project includes: Consultant employee type Department Manager employee type Executive Manager employee type Full Time Employee employee type Part Time Employee employee type Temp Employee employee type Project administrators may define employee types in the Address page of the Employee View folder Defining Registration Methods Administrator-defined registration method rules determine whether employees may automatically access and work in the Employee Web Portal after they have selfregistered or whether they are sent a password by that enables them to log into the Employee Web Portal. Project administrators may define the employee registration method for a Employee Web Portal the Registration Control page of the Registration Control subfolder of the Employee Web Portal folder in the ServiceWise Admin client. The Direct Access after Registration registration method The Notify User with an First for Access Password registration method Defining Web Portal Registration Notifications To define Employee Web Portal registration notifications: 1Select the Auto-send for Newly Registered Employee check box in the Notification page in the Registration Control subfolder of the Employee Web Portal folder in the ServiceWise Admin client If this option is enabled an is automatically send to the employee containing the user name and password. The is sent regardless of the registration method selected by the administrator. For more information see See Defining Registration Methods on page Define the title of the notification in the Title text box control. 3Define the body of the notification in the Message control. 4To restore the default notification message, click the Default button. The default notification message includes variables that represent the employees address and password. Based on registration data, we have created a login account to our Employee Web Portal. Your login address and password are listed below: Login { Address} Password: {Password} Page 94 of 145

95 Note that your password is case sensitive and your login name is your active address. To auto login, click (and bookmark) the URL link below: {Auto Login} To manually login, click (and bookmark) the URL link below: {Manual Login} 14.5 Managing Web Themes A web theme is a set of cascading style sheets that may be used to define the look-and-feel of the Employee Web Portal. Web themes enable administrators to quickly define the color schemes, fonts, and images displayed to employees in the Employee Web Portal. Project administrators may use controls in the Web Style Setup subfolder in the Employee Web Portal folder to select, customize, and schedule web themes. Figure 14-6: Web Style Themes Page TechExcel ServiceWise enables businesses to completely customize their Employee Web Portal to be consistent with their company web site. Project administrators may customize the look-and-feel to include company logos, background colors, foreground images, fonts, and much more. Each page in the Web Style Setup subfolder enables administrators to define a different aspect of web themes: The Theme Customization page enables administrators to select a web theme. The Theme Schedule page enables administrators to customize web themes. The Field Access Control page enables administrators to create a time schedule for rotating multiple web themes. Project administrators may choose to use either custom cascading style sheets or ServiceWise web themes to format the appearance of the Employee Web Portal. Web themes, unlike style sheets, are managed in the TechExcel ServiceWise Admin client using controls in the Theme Customization page. Web Theme management tasks include: Importing Web Themes Exporting Web Themes Defining Default Web Themes Creating New Web Themes Editing Web Themes Deleting Web Themes Understanding System-Defined Web Themes TechExcel ServiceWise is delivered with four system-defined web themes: the TechExcel Default web theme, Simple web theme, Blue web theme, and the Green web theme. System-defined web themes cannot be edited or deleted. Project administrators may, however, use a system-defined web theme as a template for creating their own customized web themes. Each of the four system-defined web themes features its own distinctive color scheme, but are otherwise identical to one another. The Red Theme web theme features scarlet GIF images and red text for highlights: Figure 14-7: Employee Web Portal Using Red Theme Web Theme The Blue Theme web theme features steel blue GIF images and blue text for highlights: Figure 14-8: Employee Web Portal Using Blue Theme Web Theme The Green Theme web theme features green GIF images and orange text for highlights: Page 95 of 145

96 Figure 14-9: Employee Web Portal Using Green Theme Web Theme Importing Web Themes Project administrators may import backed up web themes in the Web Style Themes page of the Employee Web Portal folder in the ServiceWise Admin client. By default all web theme backups are saved to the ServiceWise Backups folder. All web theme backups are saved in a proprietary TechExcel ServiceWise Web Theme File (HWT) format. To import a web theme: 1Select an administrator-defined web theme in the Web Theme list in the Web Style Themes page. 2Click the Import Theme button in the Web Style Themes page. 3The Web Theme Import dialog box appears. 4Click the File button. The Import Theme file browser appears. 5Navigate to a directory. By default the Export Theme control saves web theme backups to the ServiceWise Backups folder. 6Select the backed up web theme and click the Open button. The Import Theme file browser closes. 7Click the OK button in the Web Theme Import dialog box. The Import Web Theme dialog box appears. 8Select an import option. To overwrite the existing web theme, select the Overwrite Existing Web Theme radio button. To create a new web theme from the selected web theme backup, select the Created as New radio button. If the Created as New option is selected, a new web theme is created. The new web theme has the same name as the existing web theme, but is defined as inactive. 9Click the OK button Exporting Web Themes Project administrators may back up web themes by exporting and saving them to disk in the Web Style Themes page of the Employee Web Portal folder in the ServiceWise Admin client. All web theme backups are saved in a proprietary TechExcel ServiceWise Web Theme File (HWT) format. By default all web theme backups are saved to the ServiceWise Backups folder. To export a web theme: 1Select an administrator-defined web theme in the Web Theme list in the Web Style Themes page. 2Click the Export Theme button in the Web Style Themes page. 3The Web Theme Export dialog box appears. 4Click the File button. The Export Theme file browser appears. 5Navigate to a directory. By default the Export Theme control saves web theme backups to the ServiceWise Backups folder. 6Click the Save button. The Export Theme file browser closes. 7Click the OK button in the Web Theme Export dialog box. The Web Theme Export dialog box closes. 8Select a web theme in the Export Theme list. 9Click the OK button in the Web Theme Export dialog box. A confirmation dialog box is displayed. 10Click the OK button Defining Default Web Themes The default web theme is the standard web theme that defines the appearance of the Employee Web Portal to all employees. If no other web theme is scheduled, the default web theme determines the color schemes, fonts, and images that are displayed in the Employee Web Portal. To define a default web theme, select an option from the Default Theme dropdown list in the Web Style Themes page of the Employee Web Portal folder in the ServiceWise Admin client. The Default Theme dropdown list displays all of the system-defined or administrator-defineactiveweb themes in the current project. Project administrators may define web themes as inactive in the Edit Existing Theme dialog box. Project administrators may define theme schedules to rotate the web themes that are used to define the appearance of the Employee Web Portal Creating New Web Themes Project administrators may create new web themes in the Web Style Themes page of the Employee Web Portal folder in the ServiceWise Admin client. To create a web theme: 1Click the New button in the Web Style Themes page. The Create a New Theme dialog box appears. 2Define a descriptive name for the web theme in the Theme Name text box control. 3Define the order in which the web theme is displayed in the Web Style Theme list by entering a number in the Display Order control. 4 Optional:To base the web theme on a previously-defined web theme, select an option from the Created From dropdown list control. 5Enter a brief descriptive note in the Theme Note control. 6Enter a CSS specification in the Standard Style Sheet Spec control. 7Identify the name of the folder that contains the images displayed in the web theme in the Image Folder Name control. 8To enable the web theme to be used, select the If Ready to Use check box. 9Click the OK button. The Create a New Theme dialog box closes Editing Web Themes Project administrators may edit administrator-defined new web themes in the Web Style Themes page of the Employee Web Portal folder in the ServiceWise Admin client. System-defined web themes cannot be edited. TechExcel ServiceWise provides four system-defined web themes: the TechExcel Default web theme, Simple web theme, Blue web theme, and the Green web theme. To edit a web theme: 1Select an administrator-defined web theme in the Web Theme list in the Web Style Themes page. System-defined web themes cannot be edited. 2Click the Edit button in the Web Style Themes page. The Edit an Existing Theme dialog box appears. 3Define a descriptive name for the web theme in the Theme Name text box control. 4Define the order in which the web theme is displayed in the Web Style Theme list by entering a number in the Display Order control. 5 Optional:To base the web theme on a previously-defined web theme, select an option from the Created From dropdown list control. 6Enter a brief descriptive note in the Theme Note control. 7Enter a CSS specification in the Standard Style Sheet Spec control. 8Identify the name of the folder that contains the images displayed in the web theme in the Image Folder Name control. 9 Optional:To enable the web theme to be used, select the If Ready to Use check box. 10Click the OK button. The Edit an Existing Theme dialog box closes. Page 96 of 145

97 Deleting Web Themes Project administrators may edit administrator-defined new web themes in the Web Style Themes page of the Employee Web Portal folder in the ServiceWise Admin client. System-defined web themes cannot be deleted. To delete a web theme: 1Select an administrator-defined web theme in the Web Theme list in the Web Style Themes page. System-defined web themes cannot be edited. 2Click the Delete button in the Web Style Themes page. A warning dialog box appears. 3Click the Yes button. TechExcel recommends that administrators have a basic knowledge of how style-sheets work before attempting to modify any of these settings. Each administrator-defined web theme may be customized in the Theme Customization page. However, administrators may not customize default themes shipped by TechExcel. Note: Many pages share the same style elements. Once an administrator has edited an element in one page; other pages that have the same one are also affected. The reason for this is to keep the whole look and feel of ServiceWise Web interface consistent. TechExcel strongly recommends that any administrator or designer plan what is to be done with the interface before any changes are made. To customize web themes: 1Highlight a theme to display and edit its corresponding style sheet information. 2Go to Themes Customization under Web Style Setup 3Select a web theme in the Select a theme drop down list. 4Select a page from the page list; all the styles used in this page will appear on the right. 5Edit its value in thestyle element valueinput box. Sample button to view the style element values from other themes Preview button to view the result administrators have made to the current page Managing Employee Web Portal Field Access Controls Employee Web Portal field access controls determine whether employees may view and edit project data-entry controls in the Employee Web Portal. Project dataentry controls are assigned one of four levels of access: the Not Visible, Visible and Editable, Visible and Read-only, and the Read-only but Editable on Submission access controls. The Employee Web Portal may display data-entry controls from the Description page and the Current Status page of the Employee view in the ServiceWise client applications. Project administrators may define employee access to the data-entry controls displayed in the Employee Web Portal using tools in the Field Access subfolder of the Page Style Customization folder. The Not Visible access control ensures that data-entry controls are not displayed in the Employee Web Portal. The Visible and Editable access control enables employees to view and edit data-entry controls in the Employee Web Portal. The Visible and Read Only access control enables employees to view, butnot editdata-entry controls in the Employee Web Portal. The Read Only but Editable at Submit access control enables employees to define properties values in data-entry controls on incident submission. The data-entry control is subsequently defined as read-only, and cannot be edited by project members. The following fields and pages are displayed in the sample support project. Page 97 of 145

98 Table 14-1: Employee Web Portal Field Access Controls 14.7 Managing Page Style Customization Project administrators may use tools in the Page Style Customization Page page of the Page Style Customization folder to customize the home page announcements, registration messages, and the New Incident page displayed in the Employee Web Portal. The Page Style Customization folder contains eight different system pages. Each system page enables the project administrator to customize a different aspect of the Employee Web Portal. The New Employee Registration page enables administrators to add or remove registration and login control placeholders and to customize the appearance of the Employee Web Portal login page displayed to unregistered employees. The Registered Employee Login enables administrators to customize the appearance of the Employee Web Portal login page displayed to registered employees. The Home Page Announcement enables administrators to customize appearance and define the announcements that are displayed in the Employee Web Portal home page. The New Registration Messages page enables project administrators to define six different messages that may be displayed to new employees when they selfregister for the Employee Web Portal. The Registered Employee Messages enables administrators to customize The New Incident Page enables administrators to customize the New Incident page that employees use to submit new incidents to work projects through the Employee Web Portal. The Incident Page List enables administrators to customize the Incident List window displayed in the Employee Web Portal. The Other Pages page enables administrators to customize the company logo, the header, and bottom section of the Employee Web Portal Login page. Page 98 of 145

99 Employee Web Portal style customization tasks include: Enabling the Employee Web Portal Home Page Managing Employee Web Portal Announcements Customizing the New Incident Page Managing the Incident List Page Customizing the Company Header Customizing Employee Web Portal Headers and Footers Customizing ServiceWise Web Logos Enabling the Employee Web Portal Home Page To enable the Employee Web Portal home page to be displayed to employees, select the Show Employee Web Portal Home Page check box the Home Page Announcement page in the Page Style Customization folder of the ServiceWise Admin client. The Employee Web Portal home page must be enabled for employees to view project-member-defined web announcements Managing Employee Web Portal Announcements Web announcementsare user-defined announcements that are visible to employees whenever they log into or visit their personal Home page in the Employee Web Portal. Web announcements may be specifically targeted to employees based on their employee type. All announcements are created, scheduled, and managed in the Knowledge view of the ServiceWise clients. Project administrators may designate different areas of the Employee Web Portal Home page as web announcement sections and enable ServiceWise project members to publish announcements to each of these announcement sections. Project administrators may add web announcement sections to the top, left, and bottom of the Employee Web Portal Home page. Figure 14-10: Employee Web Portal Home Page Project administrators may create web announcement sections, define the display order of those announcement sections in each area of the home page, and define the number of announcements that may be published to each announcement section using controls in the Home Page Announcement page in the Page Style Customization folder of the ServiceWise Admin client. Note:Web announcement sections are only displayed in the Employee Web Portal if a web portal announcement is published to that web announcement section. If no announcement is posted to an announcement section, that section and its headers and frames are ignored. To add announcement sections to the home page: 1Click the Add button in the Home Page Announcement page in the Page Style Customization folder of the ServiceWise Admin client. The Section dialog box appears. 2Define the title of the announcement in the Section Title text box control. All announcements posted to a section appear under a single section title. The section title may describe the types of announcements that are posted to that announcement section. For example,product Announcements,Company News,Coming Events,Service Center Updates. 3Select an option from the Position Option dropdown list. The Position Option dropdown list may display three distinct options which represent the different areas of the Employee Web Portal home page in which an announcement section may be placed. Main body top sections are displayed in the center of the Employee Web Portal home page above the incident list. Only one main body top section can be defined. Main body bottom sections are displayed in the center of the Employee Web Portal home page below the incident list. Multiple sections can be defined for the main body bottom section. Side bar sections are displayed in the left hand frame of the Employee Web Portal home page. Multiple sections can be defined for the side section 4Enter a number in the Display Order text box control. Display order numbers define the order in which announcement sections are displayed relative to other announcement sections in the Main Body Bottom and Side Bar home page positions. (Only one announcement section may be added to the Main Body Top home page position). Note:Use larger numbers (10, 20 or 100, 200.) rather than single digits to represent announcement section display orders. Single digit display orders (1,2,3) restrict the ability of administrators to position new announcement sections between existing announcement sections. 5Enter a number in the Max Number text box control. Project administrators may define the maximum number of web announcements that may be published to each web announcement section. 6Enter a brief note describing the announcement section in the Section Notes control. Announcement section descriptive notes are not displayed in the Employee Web Portal. 7Click the OK button. The Section dialog box closes Customizing the New Incident Page Project administrators may customize the New Incident Page displayed in the Employee Web Portal in the New Incident Page page of the Page Style Customization folder in the ServiceWise Admin client. Page 99 of 145

100 Figure 14-11: New Incident Page The New Incident page enables employees to submit new incidents to a project through the Employee Web Portal. Project administrators may configure the labels and the links associated with creating new incidents. These elements all accept both plain text and HTML code. On the Employee Web Portal home page, between the Knowledge base quick search and the project incident list is a link to the form that employees use to create new incidents. This link is made up of three parts: a page title, header above the link, the link itself, and some descriptive text below the link. Customize each of these settings: Page title New incident project selection header New incident HTML link title New incident submit help note New incident based on incident template Page title When a employee clicks on the new incident link the new incident page displays. Use the New incident page title field to customize the title of this new incident page. If this field is left blank, the new incident page will have the default title, New Incident New incident project selection header Use the New incident project selection header field to create a header that appears above the link to the new incident form. For example, an administrator may add a note stating: Submit a new support request as a header New incident HTML link title Use the New incident HTML link title field to configure the words that make up the link itself. For example, an administrator may add a note stating: Click here to create a new support incident as a link New incident submit help note Use the New incident submit help note field to configure the descriptive text that will appear below the link to the new incident page. For example, an administrator may add a note stating: Be sure to search the knowledge base for an answer to your question before clicking on the link above to create a new support incident New incident based on incident template Use the Project incident list header input box to configure a header for the list of project incidents. The default value for this field (if left blank) will show the text Support Incident List followed by the project name Managing the Incident List Page Project administrators may use tools in the Incident Page List page of the Page Style Customization folder to determine which columns are displayed in the Incident List page in the Employee Web Portal. Figure 14-12: Incident Page List Page The Incident List window displays high-level information about many different incidents in a tabular format. Each row represents a single incident. Each column represents an incident property. In the ServiceWise sample project 15 distinct incident properties may be displayed in the Incident List page of the Employee Web Portal. Assigned By Current Owner Employee Priority Database Date Assigned Date Closed Employee Incident ID Planned Finish Date Planned Start Date Problem Detail Problem Type Progress Status Request Type Chapter 15 Administering Web Forms 15 Chapter15 -- Administering Web Forms In this chapter: Administering FormWise Web Forms Administering FormWise Autoreply Understanding the FormWise Information Schema 15.1 Administering FormWise Web Forms Project administrators may enable web clicks, web points, employee profiling, and form management in the General Settings page of the Web Activity and FormWise folder in the ServiceWise Admin client. Web clicksenable project teams to record Employee Web Portal activity so that they may track employee interest in products and services. Page 100 of 145

101 Web pointsenable project teams to assign points to pages, links, or the answers given to form questions to gauge employee interest. FormWise formsenable project teams to gather employee data with user-defined form questions and form templates. Employee profile questionsenable project teams to link form questions to employee data that is managed in ServiceWise projects. All FormWise settings are defined on aproject-by-projectbasis. Support for Web Activity tracking, forms, web points and other FormWise features may be enabled in one project and disabled in or projects within the same TechExcel ServiceWise implementation. Note:FormWise is an optional feature in ServiceWise projects and project administrators must enable support for FormWise within their project using controls in the Optional Features page of the General Project Settings folder in the ServiceWise Admin client. Once project administrators have enabled support for FormWise features within their projects, they may enable and define individual FormWise features in the General Settings page of the Web Activity and FormWise folder. Targeted announcements may be sent to employees based the answers given to form questions. Project administrators may pre-schedule these announcements. FormWise administrative tasks include: Enabling Web Activity Management (Web Clicks) Enabling FormWise for Standard Forms Enabling Employee Profile Questions Defining the FormWise URL Administering Web Points Defining Web Points Access Controls Enabling Web Activity Management (Web Clicks) Web clicks enable project teams to record Employee Web Portal activity so that they may track employee interest in products and services. Each page viewed by a employee may earn that employee a set number ofweb pointsbased on the link clicked. To enable project teams to track employee web activity usingweb clicks, select the Enable Web Activity Management check box in the General Settings page of the Web Activity and FormWise folder Enabling FormWise for Standard Forms To enable project teams to create and manage standard FormWise forms, select the Enable FormWise for Standard Forms check box in the General Settings page of the Web Activity and FormWise folder. Project administrators must enable support for standard forms in their project for ServiceWise project members to publish forms Enabling Employee Profile Questions When designing forms, project members may limit the range of employee profile questions based on one of three criteria: Only for those 100% confirmed employees Include employees based on addressed matched Never update employee profile for this form To enable project teams to update or define employee profiles based on answers given to form questions, select the Support Employee Profile Questions check box in the General Settings page of the Web Activity and FormWise folder. Employee profile questions are linked directly to employee account properties defined and managed within the ServiceWise client application. User-defined form dropdown lists may be mapped to ServiceWise properties and display incident property values as selectable options Defining the FormWise URL To define the root folder for all project forms, enter a URL in the FormWise URL text box in the General Settings page of the Web Activity and FormWise folder. The default URL for FormWise forms is: By default the name of the FormWise root is namedformwise. Project administrators may give any name they choose to this directory, but the name must match the alias given to the QuickInfo folder stored in the IIS server. The default directory for storing all FormWise forms: inetpub\wwwroot\quickinfo. Project administrators must share the QuickInfo folder and define an appropriatealiasto make the form available Administering Web Points Web points are automatically generated for users that execute tasks in the a web form in the Employee Web Portal (answering profile questions) or Download Plus (downloading knowledge items or applications). Businesses may target potential or existing employees based on the number of points they have earned while surfing their Employee Web Portal. Project administrators may enable web points and define web point settings for their projects using controls in the n the General Settings page of the Web Activity and FormWise folder. Project administrators may define rules for identifying leads based on web points: Enabling web points Defining the applicable date range for auto-calculating web points Defining the applicable point range for searching out employees Displaying the TCP/IP address of web points Defining the number of web points earned for logging into the Employee Web Portal and Download Plus To administrate web points: 1Select the Support Web Activity points check box in the General Settings page of the Web Activity and FormWise folder. Project administrators must enable web point support in a project for TechExcel ServiceWise to track and calculate new web points. 2 Optional:To define the applicable date range for auto-calculating web points, select the Number of Days to Auto Calculate Web Points for Employees and Contacts check box. ServiceWise calculates employee web points based on web activity (web clicks) within an administrator-defined time period. By limiting the date range of web point calculation, project teams may ensure that only fresh data is considered when identifying new leads. The default setting is 30 days. 3 Optional:To define the applicable point range for employee accounts, define a low and high number in the Default Web Points for Searching Active Users area. The low number represents the lowest number of web points that a employee must earn to be returned by a search. The high number represents the highest number of web points that a employee must earn to be returned by a search. 4 Optional:To display TCP/IP address for employee web activity, select the Show TCP/IP Address for Employee Web Activity check box. 5 Optional:To display the Web Activity Points page, select the Show Web Activity Points Page check box. 6 Optional:To define the number of web points assigned to a employee for logging into the Employee Web Portal, select the Assign Employee Web Portal Login with Web Points check box. 7 Optional:To define the number of web points assigned to a employee for logging into DownloadPlus, select the Assign DownloadPlus Login with Web Points check box Defining Web Points Access Controls Project administrators may grant web point management privileges to project members using controls in the Privileges page of the Web Activity and FormWise folder. Web point privileges enable project members to manage web points and web clicks in ServiceWise projects based on their account type. All ServiceWise privileges are granted to account types rather than directly to project members. Page 101 of 145

102 Table Administering FormWise Autoreply Targeted may be sent to customers based on administrator-defined FormWise autoreply rules. FormWise autoreply administrative tasks include: Enabling Autoreply Defining Server Information Enabling Autoreply To enable TechExcel ServiceWise to automatically send announcements to customers based on data collected in web forms, select the Enable Auto Reply check box in the Outgoing Mail Setup page of the Web Activity and FormWise folder Defining Server Information To define the outgoing server: 1Define the outgoing mail server in the Outgoing Mail (SMTP) Server field. The account information can be either a domain user account or the server computer account with privileges of using the outgoing mail server service. 2To define the return address, enter the address and the user name of the addressee in the fields provided. All replys to the ServiceWise generated notifications are automatically addressed to the address and the user name defined. 3If the server requires authentication, select the My Server Requires Authentication check box and define the account name and password in the fields provided Understanding the FormWise Information Schema FormWise WebAccessFormCatagory:This table will give project members the names of the categories project members set up when in the client and accessing the Tool menu and choosing FormWise Setup. The form categories project members see in the left panel tree view is that categories from this table. FormCatagoryID Name WebAcccessForm:This table will give project members the names of the forms project members set up while still in the FormWise Setup. It links back to the WebAccessFormCatagory table through the FormCatagoryID value. WebAccessFormID FormCatagoryID Name WebAccessFormQuestions:This table will give project members the id of the question (ProfileQuestionID) which maps back to the WebAccessForm through the value stored in the WebAccessFormID. This table does not give project members the names of the questions, but id's. WebAccessFormID ProfileQuestionID CProfileCatagory :This table gives project members the category that each question is in. This can be accessed through the Tool menu and choosing FormWise Questions. The questions will show up in the right panel while the question categories will show up in the left hand panel. This table gives us the data on the left hand panel. ProfileCatagoryID Name CProfileQuestions :This table gives us the names of the actual questions and is linked back to the CProfileCatagory table through the ProfileCatagoryID. ProfileQuestionID QuestionTitle ProfileCatagoryID CProfileChoices :If for the question there are choices, meaning that this question is not a fill in answer, then their will be choices that will be the answer to the questions. This data is stored in this table and is linked back to the CProfileQuestions through the ProfileQuestionID field. ProfileChoiceID ProfileQuestionID ChoiceText CProfileAnswerNote :This table stores the answer to the questions that are fill in answers and not choice answers. It maps back to the CProfileQuestions table through the ProfileQuestionID field and is linked to the correct customer through the CustomerID field. ProfileQuestionID CustomerID AnswerNote CProfileAnswers :This table stores the answers to the questions that had choices. It maps back to the CProfileChoice table through the ProfileChoiceID field, mapped back to the CProfileQuestions table through the ProfileQuestionID field, and mapped to the specific customer through the CustomerID field. ProfileQuestionID ProfileQuestionID CustomerID DateAnswered AnsweredByContactID Answer Web Clicks Manager WebClicks :The data stored in this table will give project members the contact or customer information on who made the web click along with their IP address and the field Name in this table stores what kind of web click was performed. WebClickID ContactID CustomerID DateVisited Name TCIP WebClickProfileNote :This table stores any answered data during the web click process that relates to fill in answers or notes. It maps back to the WebClicks table through the WebClickID, it maps back to the CProfileChoices table by the ProfileChoiceID, the CProfileQuestions table by the ProfileQuestionID, and the Customers table through the CustomerID. WebClickID ProfileChoiceID ProfileQuestionID CustomerID DateAnswered CustomerNote WebClickProfiles :This table stores answers to web click questions that map back to the profile questions that have choices. WebClickID ProfileChoiceID ProfileQuestionID CustomerID DateAnswered Answer WebClickAddress :This table stores address data that can be linked to the web click and having that person fill out a form telling their address info. It maps back to the WebClicks table through the WebClickID. Chapter 16 System-Level Web Administration 16 Chapter16 -- System-Level Web Administration This chapter describes the configuration and maintenance of the ServiceWise Web Server and other administrative tasks that support ServiceWise Web. Topics include enabling and managing single sign-on settings, interproject switching, and configuring support for multiple ServiceWise Web Servers. Page 102 of 145

103 In this chapter: Managing System-Level ServiceWise Web Settings Defining Web Publishing Access Options Administrating ServiceWise Web Support and System-Level Settings Managing ServiceWise Web System Settings Managing Multiple Web Server Support Managing Interproject Switching 16.1 Managing System-Level ServiceWise Web Settings The ServiceWise Web Server is an add-on component that enables project members to access work projects over the Internet using web browsers. The ServiceWise Web Server needs to be installed if users must access ServiceWise through the Web. TechExcel recommends installing the ServiceWise Admin module on the ServiceWise Web Server computer so that changes made to the ServiceWise Web Server can be quickly modified in ServiceWise Admin. System administrators may use tools in welcome message Admin to manage general welcome message Web settings and welcome message Web image settings for an entire welcome message implementation. All system-level ServiceWise Web settings are defined at the System Settings project in the ServiceWise Admin client. The ServiceWise Web Server configuration dialog box enables system administrators to define and update the connections between the ServiceWise Web Server and the ServiceWise Application Server and the ServiceWise Database Server. The Web Support manager enables administrators to define the server path for the ServiceWise Web Server, the system runtime key, Issue List and reporting refresh options, and the welcome messages displayed in ServiceWise Web and the Employee Web Portal. The Web Image and Multimedia Attachment Settings dialog box enables administrators to enable project members to add images, movies, and sound to issues as attachments and to define the maximum size for these files. The Web Authentication dialog box enables administrators to define the method the ServiceWise system uses to authenticate project members logging into ServiceWise Web. ServiceWise supports three methods: ServiceWise login and password, Windows NT authentication, third-party authentication. Interproject switching enables ServiceWise Web client users to switch quickly between a ServiceWise project and other TechExcel projects (TechExcel DevTrack, TechExcel CustomerWise) Defining Web Publishing Access Options System administrators may use controls in the Web Server Access to Document Server area of the Document Server page to define how the TechExcel ServiceWise Web publishing service communicate with the ServiceWise Document server. The Web file publishing service gets a copy of the requested document from the ServiceWise Document Server whenever a project members requests a document through the ServiceWise Web Server. The document is then published to the Web file folder for downloading. Administrators may enable and define one of three access options: The Direct Access through a Local Path on the Web Server enables the administrator to directly link the ServiceWise Web Server and ServiceWise Document Server. This option is available if the ServiceWise Document Server is installed on the same computer as the ServiceWise Web Server. The folder containing the ServiceWise Document Server must be shared, so it is possible that files could be accessed from the network path if the folder settings are not correctly configured. Only administrators that know how to define folder permissions that meet company security standards should use this access method. TechExcel does not recommend the Direct Access option. The Direct access through a Network Path enables the administrator to link the ServiceWise Web Server and ServiceWise Document Server on the network. Only administrators that know how to define folder permissions that meet their company security standards should use this access method. The folder containing the ServiceWise Document Server must be shared, so it is possible that files could be accessed from the network path if the folder settings are not correctly configured.techexcel does not recommend the Direct Access option. The TCP/IP access to the Document Server option is the configuration recommended by TechExcel. This method uses TCP/IP protocol to access the folder that contains the documents and is the most secure approach Defining Client Access Administrators may choose between two options for defining TechExcel ServiceWise Windows client access to the ServiceWise Document Server. TCP/IP access to the document server this is the suggested choice for allowing the client applications to access the documents in the document server. This method uses TCP/IP protocol to access the folder that contains the documents and is the most secure approach. Direct access through the following network path this method is not recommended, but is an option for advanced users that know how to set the folder permissions to meet their company security standards. The document server folder will need to be shared, so it is possible that files could be accessed from the network path if the folder settings are not correctly configured Administrating ServiceWise Web Support and System-Level Settings System administrators may define general ServiceWise Web Server settings in the Web Server Setting page in the System Setting project. The Web Server Setting page enables administrators to define system runtime keys, enable database connection pooling, and define default settings for projects displayed in the ServiceWise Web client. ServiceWise Web Server settings may be defined in the System Settings project only. System-level ServiceWise Web Setting apply to every project in a ServiceWise site. Administrators may enable and define three ServiceWise System Web Settings in the General Settings page: Defining the System Runtime Key Enabling Database Connection Pooling Defining the Number of Records in ServiceWise Web Defining ServiceWise Web Login Titles Defining the System Runtime Key Administrations may use the Web Support page to define a system runtime key for a ServiceWise project. When the administrator has defined both the project runtime key and the system runtime key, project members may access ServiceWise through two different URLs, each with the appropriate level of access. System runtime keys may either be used in conjunction with a project runtime key or on their own to add an additional level of security to a project. Companies that maintain several ServiceWise projects and who wish to restrict access to certain projects may use a system login key in combination with the project runtime key. The system runtime key may also be used without project runtime keys. In this situation only team members that know the system runtime key will have access to ServiceWise projects. With runtime keys adding another level of access control, the following configurations are possible for a company: Option 1 Enable users to access all ServiceWise projects if the correct system runtime key is specified. The format for including the system runtime key is as follows: clogin.dll?runtimekey=systemkey Option 2 Enable users to access the login page for a project that has no runtime key (by leaving the project runtime key blank). The format for accessing a project with no runtime key is as follows: clogin.dll?projectid=# Enable users to access the login page for a project that has a runtime key by passing both the project ID and runtime key in the URL. Page 103 of 145

104 The project ID or a project can be found by selecting File > Open Project in ServiceWise Admin. The project ID is displayed next to each project. Note:The system runtime key does not replace the Web login process; it is an additional level of access control. After passing the appropriate runtime key, user authentication is still required toaccess a project Enabling Database Connection Pooling Database connection pooling may improve the performance of TechExcel ServiceWise Web based on the current database system. This function works for all supported databases. With database connection pooling enabled, the ServiceWise Web Server can maintain up to 80 connections Defining the Number of Records in ServiceWise Web System administrators may define the number of records displayed in the ServiceWise Web client and Employee Web Portal using controls in the Web Server Setting page. The List View Page Size control enables system administrators to define the number of records displayed in the Incident List window. TechExcel recommends that between 20 and 500 records are displayed. The Employee Dropdown List Size enables system administrators to define the number of options displayed in the Employee dropdown list control. TechExcel recommends that between 20 and 500 records are displayed The Report Page Size control enables system administrators to define the number of records displayed in list reports. TechExcel recommends that between 20 and 500 records are displayed The Incident List Page in Employee Web Portal control enables system administrators to define the number of records displayed in the Incident List window of the Employee Web Portal. TechExcel recommends that between 10 and 100 records are displayed Defining ServiceWise Web Login Titles The ServiceWise Login page displays controls that enable project members to log into a ServiceWise project using their user name and password. The ServiceWise Login page consists of the three sections: the web login title, the welcome message, and the login controls. ServiceWise Login page titles and welcome messages may be defined at both the system level and the project level. Project Login page titles and welcome messages are only displayed in the ServiceWise Web client if the user passes the project ID in the URL. If the project ID is not passed in the URL, the ServiceWise client automatically loads the system title and welcome message. To define the ServiceWise Web Login page at the system level, enter HTML markup in the Web Login Title multiple-line text box of the Web Server Setting page in the General System Settings folder of the system settings project. By default, the following markup is entered in the Web Login Title multiple-line text box: rel="stylesheet" type="text/css"> cellspacing="0"> Defining Web Welcome Message The ServiceWise Login page displays controls that enable project members to log into a ServiceWise project using their user name and password. the ServiceWise Login page consists of the three sections: the web login title, the welcome message, and the login controls Managing ServiceWise Web System Settings System administrators may define the URLs that project members and employees use to access ServiceWise Web and the Employee Web Portal in the Systems Settings page in the General Settings page. ServiceWise Web System Settings may be defined in the System Settings project only. Administrators may choose to designate separate ServiceWise Web Servers to host the login paths for project members and for prospects or employees. Using separate ServiceWise Web Servers provides enhanced performance and security. Administrators may enable and define three ServiceWise System Web Settings in the General Settings page: Defining the Web Server Path for Employees Defining the Web Server Path for Project Members Enabling Project Member Logins Using Domain Accounts Defining the Web Server Path for Employees To define the ServiceWise Web Server path for employees, define the path in the Web Server Path for Employees text field. The path defined represents the path that employees use to log into the TechExcel ServiceWise Employee Web Portal; for example, Defining the Web Server Path for Project Members To define the ServiceWise Web Server path for project, enter the path in the Web Server Path for Project Members text field. The path defined represents the path that project members use to log into TechExcel ServiceWise Web projects; for example, Enabling Project Member Logins Using Domain Accounts System administrators may enable ServiceWise project members may log into to TechExcel ServiceWise using their domain user accounts. With this option enabled, internal project members may log into TechExcel ServiceWise Web using their domain user account, bypassing the Web login page. To enable project member logins using domain accounts, select the Team Members Login to TechExcel ServiceWise Using Domain User Account check box in the General Settings page Managing Multiple Web Server Support In ServiceWise, system administrators may identify and define multiple ServiceWise Web Servers for their ServiceWise projects for ServiceWise Web load balancing. System administrators may define the host and IP addresses of multiple ServiceWise Web Servers in the Multiple Web Server Support page. Figure 16-1: Multiple Web Server Support Page To enable multiple ServiceWise Web Servers: To enable multiple ServiceWise Web Server support, select the Enable Multiple Web Server Support button in the in the Multiple Web Server Support page. To define a ServiceWise Web Server: 17Select the Add New button in the Multiple Web Server Support page. The Add Web Server dialog box appears. 18Define the host machine and IP Address of the ServiceWise Web Server. 19To define the ServiceWise Web Server as the default ServiceWise Web Server for the ServiceWise site, select the Is Primary Web Server check box. 20Click the OK button Managing Interproject Switching Companies using TechExcel CustomerWise or TechExcel DevTrack may enable project members using the ServiceWise Web clients to switch between ServiceWise projects and CustomerWise or DevTrack projects. Page 104 of 145

105 Administrators may use the interproject Switching page to enable and define interproject switching for ServiceWise Web client users. To enable and define interproject switching settings: 1Select the interproject Switch page in the System Message folder of the Admin Tree window of the System Setting project. 2Define the path of the current TechExcel ServiceWise Web Server in the DevTrack Server field. 3Define the path of the current TechExcel ServiceWise Web Server in the TechExcel ServiceWise Server field. 4To enable switching between TechExcel ServiceWise and TechExcel DevTrack. Click the Switching between DevTrack and TechExcel ServiceWise Project check box. Define the path of a TechExcel DevTrack Server in the TechExcel DevTrack Web Server field. Click the Connection Test button to test the connection. 5To enable switching between TechExcel ServiceWise and TechExcel CustomerWise. Click the Switching between TechExcel ServiceWise and TechExcel CustomerWise check box. Specify the path of a TechExcel CustomerWise Server in the TechExcel CustomerWise Web Server field. Click the Connection Test button to test the connection. 6Click the OK button. login_web.jpg" width="520" height="146"> align="center"> border=0> border=0> Chapter 17 Company Asset Administration 17 Chapter17 -- Company Asset Administration This chapter describes how project administrators may configure asset inventory to manage products and assets in TechExcel ServiceWise and AssetWise projects. In this chapter: Understanding Asset Inventory Administration Managing Asset Template Subassets Managing Asset Template Breakdowns Customizing the Description Page Customizing the Value Page Customizing the Support Plan Page Managing Asset Custom Pages Managing Product Upgrade Rules in the Asset Inventory 17.1 Understanding Asset Inventory Administration TechExcel ServiceWise and AssetWise each use an administrator-defined Asset Inventory to represent company product and asset structures. The structures defined by administrator determine which products and assets may be managed in a project, how they are managed, and by whom they are managed. In TechExcel ServiceWise the Asset Inventory defines company assets for help desk management purposes. Every asset is based on an administrator-defend asset template.project administrators may configure the Asset Inventory in both ServiceWise projects: Understanding the Asset Inventory The Asset Inventory enables project members to define, view, and update asset properties in the client application. Every asset is represented by a set of unique properties that distinguish that item from the other assets tracked in the project. Project administrators may define how products and assets are represented in projects by customizing the data-entry controls that project members use to define assets in TechExcel ServiceWise and AssetWise projects. The Asset Inventory may display four system pages and up to ten custom pages. Project administrators may customize each of these pages by adding, removing, or customizing system-defined and custom controls. TheDescription tabenables administrators to customize the data-entry controls displayed in the Description page and choose whether an asset template may be used to track individual asset items or the quantity and usage of assets. TheValue tabdisplays a set of edit box controls that may be used to define system-level properties. Value page data-entry controls are only customizable at the system level. TheSupport Plan pageenables administrators to define the support plan and contract options and to customize the data-entry controls displayed in the Support Plan page. Thecustom pagesenables administrators to create custom data-entry controls to track administrator-defined asset properties. Project administrators may add up to ten custom pages to the client applications Understanding Asset Definition and GUI Customization Project administrators may add, remove, or customize system-defined and custom controls to the Asset Inventory at three different levels: the system level, the category level, and the template level. Asset Inventory definitions are inherited from top to bottom. System-level properties are inherited by all categories. Category-level definitions are inherited by child templates. Template-level customizations are not visible in the parent category. System-level asset propertiesare shared by every asset in a project. Adding or customizing a control at the system-level ensure that every asset is defined by that property. System-level properties are inherited by asset category andcannotbe overridden by category-level definitions or template-level definitions. System-level properties are generally rare. Category-level asset propertiesrepresent properties that are shared by by many but not all assets.category-level customizations enable administrators to define broad categories of assets that are identified by a unique set of properties. Asset categories might include applications, servers, or laptops. Custom controls defined at the category level are inherited by every asset template that belongs to that category. Template-level asset propertiesrepresent properties that are specific to a single asset. Template-level customizations enable administrators to define the asset templates that represent specific assets or products in AssetWise and TechExcel ServiceWise. Project members use asset templates to create new assets in their projects. Custom controls defined at the template level are specific to a single asset template and are not displayed in any other asset template in the project. Customizing the data-entry controls that project members use to define assets requires careful planning and testing. Project administrators may make customizations to the Asset Inventory at each level. But not every customization can be made at every level: Customizing the data-entry controls that project members use to define assets requires careful planning and testing. Project administrators may make customizations to the Asset Inventory at each level. But not every customization can be made at every level: Page 105 of 145

106 Table 17-1: Asset Description Page Customizations Understanding System-Level Asset Properties System-level asset properties are shared by every asset managed in a project. Project administrators may add or customize system or custom controls at the system level. Controls customized at the system level cannot by customized at the category or template level. System-level properties are inherited by every category of asset andcannotbe overridden by category-level definitions or template-level definitions. Generally, the number of asset properties that are defined at the system level is extremely rare. System-level customizations are generally limited to the following: Adding or removing one or more system-defined dropdown list controls in the Description page. Editing the field label for controls in the Description page. Customizing Value page data-entry controls. These controls cannot be defined at the category level or the template level Understanding Category-Level Asset Properties Category-level asset properties enable administrators to define multiple categories of assets that are identified by a unique set of properties. Project administrators may define asset categories by customizing data-entry controls at the category level. Every asset that belongs to that asset category displays the dataentry controls and control customizations made to the Asset Inventory for that category of asset. Asset categories represent groups of assets that share many properties in common. Examples of asset categories might include applications, servers, laptops, or desks. Figure 17-1: Asset Categories and Asset Templates Every asset in the Asset Inventory is represented by an asset template. Every asset template is the child of a parent asset category and inherits data-entry controls from the parent category. Project administrators may define appropriate properties at the category level and these controls are manifested by every asset that belongs to that category. The laptop asset category represents three asset templates: the Toshiba, ThinkPad, and Dell asset templates. Data-entry controls defined by the administrator at the category level are inherited by every template belonging to that category Understanding Template-Level Properties Template-level asset propertiesrepresent the properties of the actual assets managed in the Asset Inventory. Every asset is represented by an administrator-defined asset template. Asset templates define the general properties of the assets managed in projects. Every user-defined asset created and managed in a ServiceWise or AssetWise project is based on an administrator-defined asset template. Asset templates inherit customizations made to the Asset Inventory at the parent category level. Project administrators must define asset categories before they can define the child asset templates. Customizations made to the Asset Inventory at the template level are unique to each asset template. Template level customizations are not visible in the parent asset category. Project members can also define some fields properties to be at the template-level and overwrite the fields category-level definition. Define the default values for as many fields as possible at the template-level. Page 106 of 145

107 17.2 Managing Asset Template Subassets Subassets represent the component parts that make up a particular asset. Every subasset is defined by three properties: the subasset relationship, the maximum quantity, and the auto-added quantity. Subassets may be defined at thetemplate level only. The Sub Asset tab is only displayed in the Template Level Properties page. Project administrators may create, edit, or delete subassets for each asset template in the Sub Asset tab of the Template Level Properties page. Figure 17-2: Select Asset Dialog Box Subassets are defined by three properties: TheSubasset Relationship propertydetermines whether the subasset asset is created manually or automatically. TheMaximum Quantity propertydetermines the maximum number of the selectedsubasset that may be associated with the parent asset. TheAuto Added Quantity propertydetermines the number of the selected subassets that are automatically associated with the parent asset. Note:Project administrators must enable subasset support in each standard asset operation. To enable subasset support, select the Asset Template control in the General Settings page in the Asset Management (AssetWise) folder. To add subassets: 1Click the New button. The Select Asset dialog box appears. 2Select an asset category in the Asset Category list. 3The Asset Template list displays all asset templates applicable to the selected asset category. 4Double-click the asset template in the Asset Template list. The Edit Sub Asset dialog box appears. Define the subasset properties: The Subasset Relationship property determines whether the subasset asset is created manually or automatically. The Maximum Quantity property determines the maximum number of the selected subasset that may be associated with the parent asset. The Auto Added Quantity property determines the number of the selected subassets that are automatically associated with the parent asset. 5Click the OK button. The Edit Sub Asset dialog box closes. 6Click the Add button Managing Asset Template Breakdowns Asset template breakdownsenable organizations to track both assets and subcategories of assets in a single asset template. Each asset template may be broken down into subgroups of the asset it represents. Project administrators may use the asset template to track both the quantity of the asset and the quantity of each subgroup of that asset. Whereas subassets represent the component parts of an asset, asset breakdowns represent groupings of that asset. For example, a sporting goods store may sell twelve balls: four white balls, four blue balls, and four red balls. The ball is the asset. The colors white, blue, and red represent the asset breakdowns. An asset breakdown of the asset template enables the sporting goods store to track both of the total number of balls sold (12) and the number of balls sold of each asset breakdown(4). Note:Project administrators must enable asset breakdown for each standard asset operation. To enable the breakdown of asset templates, select the Enable Breakdown of Asset Template control in the General Settings page in the Asset Management (AssetWise) folder Customizing the Description Page In the AssetWise and ServiceWise clients project members use the Description page to define, view, and manage asset properties. Project administrators may customize the data-entry controls displayed in the Description page to track data that represents the assets managed in the project. Project administrators may customize the Description page at the system level, category level, and template level. The customizations that administrators may make to the Description page are different at each level. Project administrators may make the following customizations to the Description page. Add or Delete system controls to the Description page. (System-level only) Add custom controls to Description page. Customize system control labels (system level only) Define system controls as mandatory or optional (system level only) Define system controls as visible or invisible Define system control default values Define usage and quantity tracking settings. Define Asset No. system control default values (template level only) Define Asset No. system control values types and prefixes (template level only) The primary customization that administrators may make to the Description page is to addsystem controlsorcustom controls. The Description page may display ten system controls and up to twelve custom controls: System controlsare system-defined controls that have a designated use in ServiceWise and AssetWise. Project administrators may make limited customizations to these controls. The system control include the Name, Description, Asset No., Serial No., Edition, Part No., Location, Unit Price, Inventory Location, and Breakdown controls. System controls be added or deleted to the Description page at the system level. These controls cannot be added or deleted at the category or template level. Custom controlsare administrator-defined custom controls that may be added to the page. Project administrators may define appropriate field labels, control types, and defined values for each control. Description page administrative tasks include: Managing System Controls in the Description Page Managing Custom Controls in the Description Page Defining Usage And Quantity Tracking Adding and Removing Custom Pages Adding Custom Controls to Custom Pages Adding Asset Definition Custom Controls Managing System Controls in the Description Page System controlsare system-defined controls that have a designated use in the project and are integrated with other TechExcel ServiceWise or AssetWise features. Project administrators may add, remove, or customize ten system controls in the Description page of the Asset Inventory. Page 107 of 145

108 All customizations made to Description page controls at the system level are inherited by all asset categories and asset templates. System controls added to the Description page at the system level may not be removed at the category or template level. System controls removed from the Description page at the system level may not be added at the category or template level. Project administrators may make only limited customizations to system controls. Every system control displayed in the Description page belongs to the dropdown list control type. The values displayed as options in these system controls are drawn from the ServiceWise database and cannot be customized by the administrator. Project administrators may customize the field labels associated with each control and define the control as mandatory, but cannot change the content tracked in those controls. The ten predefined system controls are: The Name text field control The Description memo field control The Asset No. text field control The Serial No. text field control The Edition dropdown list control The Part No. dropdown list control The Location dropdown list control The Unit Price dropdown list control The Inventory Location dropdown list control The Breakdown dropdown list control The Inventory Location control Managing Custom Controls in the Description Page Custom controlsare administrator-defined controls that are fully customizable. Project administrators may define appropriate field labels, control types, and defined values for each control. Project administrators may add up to twelve custom controls to the Description page. Custom controls may be added to the Description page at the system level, category level, or template level. Custom controls defined at the system level are inherited by all asset categories and asset templates. Administrator-defined customizations include: Defining the field label titles for controls Choosing an control type for the control. Defining whether a control is mandatory or visible in the client. Defining default values for controls Defining selectable options displayed in dropdown list controls Defining Usage And Quantity Tracking Project administrators may classify assets by their tracking requirements in the Description page. The Track Usage and Quantity controls in the template-level Description system page enables administrators to choose how that asset is tracked in the project: as an individual item, by is use and quantity, or not at all. Figure 17-3: Track Usage and Quantity Controls Project administrators may choose one of three options for each asset template. Asset tracking requirements may be defined at thetemplate level only. TheTrack Individual Asset Item optionis used for assets that are tracked by a model number as well as a manufacturer serial number. For example, notebook computers and cellular phones. TheTrack Usage and Quantity optionis used for assets that are tracked only by an asset number and quantity, but not by a manufacturer serial number. For example, tracking the usage of software with a fixed number of licenses. TheNo Track optionis used for assets that are tracked by association with other assets, but not tracked individually. For example, screws for a notebook computer Customizing the Value Page In the AssetWise and ServiceWise clients project members may use the Value page to define, view, and manage the value of assets. The Value page displays eight edit box controls. By default these controls are used to track the following asset properties: purchase price, purchased from, purchase location, purchase date, invoice number, registration number, present value, and manufacturer. Value page controls may be customized at the system level only. No changes or customizations may be made to these controls at either the category level or the template level. Project administrators may make limited customizations to each edit box control: Rename the control Define a default values for the control Define the control as invisible Define the control as mandatory on submission 17.6 Customizing the Support Plan Page In the AssetWise and ServiceWise clients project members use the Support Plan page to view, define, and edit applicable support plans. Project administrators may customize many of the data-entry controls displayed in the Support Plan page to track data that represents the assets managed in the project. The Support Plan page displays eight data-entry controls that are displayed in two areas: the Support Plan area and the Contract area. The Support Plan area displays the Plan Name dropdown list control, Plan Status dropdown list control, the From edit box control, and the To edit box control. The Contract area displays the Contracted With dropdown list control, Contract Item dropdown list control, the From edit box control, and To edit box control. All contract data-entry controls are fully customizable. Project administrators may not add additional system controls or custom controls to the Support Plan page. Project administrators may make the following customizations to every data-entry control displayed in the Support Plan page: Rename the control Define the default value Define the control as invisible Define the control as mandatory on submission Two of the data-entry controls displayed in the Support Plan area are linked to a service agreement. Project administrators may not define the options displayed in the dropdown lists. ThePlan Name dropdown controlenables the administrator to define the name of support plans in the project. The support plans displayed as options in the Support Plan dropdown list are tied to a service agreement. ThePlan Status dropdown list controldisplays options defined in the Service Agreement Status page Managing Asset Custom Pages Project administrators may define how assets are represented in projects by customizing the data-entry controls displayed in custom pages. Project administrators may create up to ten custom pages and define custom data-entry controls that are displayed in those pages. Project members use data-entry controls to define and track asset properties in TechExcel ServiceWise projects. Project administrators may use the General Settings page in the Asset Inventory folder to add up to ten custom pages to the Asset Inventory, define the display order for each page, and define the display name Adding and Removing Custom Pages To add or remove custom pages: Project administrators may choose the number of custom pages displayed in Asset Inventory by selecting an option from the Number of Custom Pages dropdown list in the General Settings page of the Asset Inventory folder. Page 108 of 145

109 Project administrators may add up to ten custom pages. Custom pages are only displayed in the Asset Inventory if the administrator has defined them as visible in the Define Custom Page Captions and Visibilities manager Adding Custom Controls to Custom Pages Project administrators may add up to twelve custom controls to each custom page. All fields can be made visible and mandatory on submission. The first eight fields are fully customizable like the fully customizable fields on the Description page. The last four custom fields are a date/time fields. Define if each field will show the date only, or the date and time Adding Asset Definition Custom Controls Project administrators may add and define custom controls to system pages and custom pages using the Add Custom Control manager. Figure 17-4: Add Custom Field Manager The Add Custom Control manager enables administrators to define seven different properties for each custom control: The Field Label property The Field Type property The Visible property The Mandatory property The If Unique property The Field Level property The Field Type attribute The Field Type attribute enables the administrator to define the control type of the custom control. The control type of the data-entry control determines the how the asset property represented in that control is defined and tracked. Project administrators may choose between eight different control types. Check Box control type Combo Box control type Date-Time control type Double Edit Box control type Drop Down List control type Integer Edit Box control type Multiple Selection control type Text Edit Box control type Field Level attribute The Field Level dropdown list is read-only in the UI Field manager. Custom controls may be added to the Description system page and all custom pages at the system-level, category-level, and template-level. The Field Level dropdown list displays the level (system, category, or template) at which the selected custom control was added to the page. Custom controls defined at the system level are fixed for all categories and inherited by all assets and products managed in the project. Custom controls defined at the category level are inherited by every asset template that belongs to that category. Custom controls defined at the template level are specific to a single asset template and are not displayed in any other asset template in the project Managing Product Upgrade Rules in the Asset Inventory Project administrators may define product upgrade rules in the Product Upgrade page. Asset upgrade rules define how assets managed in the Asset Inventory may be upgraded in the project. All upgrade rules are defined on a template-by-template basis. Every asset in the Asset Inventory is represented by an asset template. Upgrading an asset is a matter of changing the asset template that defines that asset. Upgrade rules define the asset template that defines the original asset, the asset template that defines the upgraded asset, and the method used to execute the upgrade. Every asset template may be associated with multiple upgrade rules. Project administrators define upgrade rules for the asset template that is used to define the upgraded asset not the asset template that defined the original asset. Project administrators may choose between three methods for upgrading assets: Convert the old asset to the new asset Create a new asset with the same asset number Create a new asset with a new asset number Note:Asset upgrade rules must be defined before that administrator may define the Upgrade asset operation in the Standard Asset Operations page Defining Asset Upgrade Rules Project administrators may define new asset upgrade rule properties in the Asset Template Upgrade manager. Figure 17-5: Asset Template Upgrade Manager To upgrade an asset template: 1Select an asset template in the Asset Template Tree window of the Product Upgrade page. The asset template selected represents the asset template that defines the new, upgraded asset. Page 109 of 145

110 2Click the Add button. The Asset Template Upgrade manager appears, 3Define a unique name and add a brief description of the upgrade rule. The Upgrade Name control enables the administrator to define a unique name for the upgrade rule. The Note control enables the administrator to add a brief description of the upgrade rule and how it is used in the project. Every asset template may be associated with multiple upgrade rules. 4Select an option from the Upgrade Method control. Project administrators may choose between three methods for upgrading assets: Convert the old asset to the new asset Create a new asset with the same asset number Create a new asset with a new asset number 5Select an option from Old Asset Option control. Project administrators may choose between three options for handing old assets: Delete the old asset Set the old asset as inactive Keep the old asset active 6 Optional:To ensure that the upgrade rule is only used to upgrade existing assets, select the Old Asset Must Exist In Order To Perform This Upgrade control. 7 Optional:To automatically update asset properties based, select the Update Asset Properties Based On Default Values Of The New Template control 8 Optional:To associate one or more asset templates with the upgrade rule, click the Add button and define the Upgrade From asset template. The asset templates added to the Upgrade From list represent the asset templates that defined the original asset. 9Click the OK button. The Asset Template Upgrade manager closes Editing Asset Upgrade Rules To edit or delete asset upgrades, highlight the upgrade rule and click the Edit or Delete buttons. Chapter 18 Knowledge Administration 18 Chapter18 -- Knowledge Administration In this chapter: Understanding ServiceWise Knowledge Management Managing Editing Tools Managing Announcements Defining Dynamic FAQs Customizing the Knowledge View Managing ServiceWise-RightAnswers Integration Backing up the Document Files 18.1 Understanding ServiceWise Knowledge Management TechExcel ServiceWise features powerful document and knowledge management tools that enable project team members to build a knowledge base of data, manage that data in a central repository that is shared across multiple ServiceWise projects, and control employee and project member access to knowledge items based on administrator-defined privileges. Knowledge management tasks may be performed in the Knowledge view of the ServiceWise clients and through the Employee Web Portal. ServiceWise enables project members and employees to add documents, topics, HTML links, announcements and attachments to the database and access knowledge items using keyword searches. TechExcel KnowledgeWise provides businesses with a forum for managing and sharing information across projects that enables them to capitalize on their expertise. A centralized knowledge base of important company documents can increase efficiency, prevent lost or misplaced information, track document histories and reduce the system and maintenance costs. Internal teams and external employees can search the knowledge base for self-service content based on administrator-defined privileges. ServiceWise knowledge base content may be linked to other knowledge base management systems. Project-level administrative tasks include: Grant knowledge management privileges to project members based on their account type. Defining the text editors that may be used to create and edit knowledge items. Configure announcement settings. Enable and define dynamic FAQ settings. Customize the pages displayed in the Knowledge view of the ServiceWise clients. Enable and configure the ServiceWise Knowledge Portal. Enable and configure integration with third-party knowledge management solutions. Enabling and configuring the TechExcel Search Engine. Enabling knowledge item auto recommendations and defining knowledge base search result ranking rules. Note:The TechExcel ServiceWise Document Server must be installed and the server settings defined for this feature to work correctly. For information on installing the document server please see the installation instructions Understanding the ServiceWise Knowledge Base Project teams may build knowledge base adding existing knowledge documents and Web pages, and by publishing knowledge items from resolved support incidents. KnowledgeWise enhances employee support process by improving support response time, speeding training for new employees, and standardizing resolutions to common issues. Project members may build knowledge by adding documents, topics, HTML links, announcements, and attachments to knowledge base from within the ServiceWise client applications. Note:Project members may build knowledge using the ServiceWise Web client only if knowledge building through the Web is supported in the ServiceWise project. Knowledge management through the Web must be enabled separately in each work project. Internal teams and external employees can search the knowledge base for self-service content based on administrator-defined privileges. ServiceWise knowledge base content may be linked to other knowledge base management systems Understanding ServiceWise Client Knowledge Management Tasks ServiceWise project members may use tools in the Knowledge view to manage knowledge items (documents, topics, HTML links, announcements, and attachments) in project knowledge base. Project administrators are responsible for enabling and configuring knowledge management features and tools and for granting knowledge management privileges to project members based on their account type. ServiceWise knowledge management tasks include: Build and manage a knowledge base of knowledge items: Project members may add, modify, delete, categorize, and index the documents, topics, HTML links, and announcements stored in the knowledge base. The ServiceWise Knowledge view enables development teams to manage all project-related knowledge items (documents, HTML links, announcements topics and attachments) including nternal design documents, system requirements, user specifications, and test cases in a central repository. Manage multiple versions of project documents: Control document actions at the project, folder, or item level. Project members may use the ServiceWise version control system to manage versioning of project documentation. Tools available in the Knowledge view and the Notes page of the Main view provide project members with Page 110 of 145

111 access to past versions of documents and ensure that only one project member may access a document at any one time. Define and manage project member and employee self-service: Provide employees with help topics, release notes, and other self-help documentation. Define keywords and relevancy of keywords for knowledge items stored in the knowledge base. Track resolved incidents: Add resolved incidents to the knowledge base to enable self-service and speed diagnosis and resolution. Searching the knowledge base for knowledge items: Full text and keyword searches ranked by relevancy. Add knowledge items as attachments to incident notes or them to other users. Extend the knowledge base by linking knowledge items to third-party knowledge management solutions. Link TechExcel ServiceWise and ServiceWise with third-party knowledge management tools Understanding Knowledge Items ServiceWise enables project members to manage knowledge items (documents, web pages, topics, and attachments) in the Knowledge view. The Knowledge view contains tools designed to manage four different types of knowledge items. The Knowledge Tree window organizes knowledge items into a hierarchy of folders. Documentsinclude all external files that saved in the ServiceWise database through the Knowledge view. Documents may either be created internally from document templates or externally using a word processing or spreadsheet program. Announcementsare predefined s that are created in the TechExcel ServiceWise client, and are then delivered to one or multiple employees also through the client. HTML linksenable project teams to create a library of project-related URLs. Development issues can be linked with a dynamically changing web site or page-based HTML document for easy reference and access. Topicsare knowledge items specifically designed to enable project teams to build a knowledge base of problems and resolutions. Each topic knowledge item consists of a description page, a resolution page, and a links page.no file is attached and the information is maintained in the database. Topics can help save time in resolving redundant issues. Attachmentsare documents that have been attached to issues in the Main view Notes page. Although these knowledge items are visible through the Knowledge view, they are managed using tools in the Notes page Managing Knowledge View Access Controls Knowledge privileges enable project members to build, publish, and manage knowledge items in TechExcel ServiceWise projects. All privileges are granted by project administrators to account types in ServiceWise projects. Project members inherit privileges when they are assigned an account type in a project. Project members assigned a light account type cannot perform any of the knowledge-related operations. Project administrators may assign 13 different knowledge management privileges to each regular account type. Page 111 of 145

112 Table 18-1: Knowledge View Access Controls 18.3 Managing Editing Tools Project administrators may enable text and HTML editing tools using controls in the General Settings page of the Knowledge view folder. TechExcel ServiceWise enables project members to create announcements and knowledge items using advanced HTML and text editing tools Choosing an Editor Project administrators may choose between four editors: Text editor Standard TechExcel web edit control. ewebedit control 20 users edition (separate purchase is required) ewebedit control unlimited users edition (separate purchase is required) Defining HTML Editor Folder The HTML editor folder contains the copies of HTM files that have been edited by project members in the ServiceWise client applications. To define the HTML Editor folder, define the local folder for HTML editor control Managing Announcements announcementsare predefined s that are created in the TechExcel ServiceWise client, and are then delivered to one or multiple employees also through the client. In TechExcel ServiceWise project members that have been granted the Can Blast Knowledge Announcement privilege may create a knowledge announcement in the Knowledge view and blast the customized to all employees with a single click. Project administrators may use controls in the Announcements page of the Knowledge view folder to enable announcement support and announcement settings in TechExcel ServiceWise projects. announcement settings are defined on a work project by work project basis. Project administrators may not define announcements in base projects. Project administrators may configure announcement properties using controls in the Announcement page of the Knowledge view folder. Note:The TechExcel ServiceWise Server programs must be installed for this feature to work correctly. The retrieval service must be installed to process incoming s, and the notification service must be installed to process outgoing s. announcement administrative tasks include: Defining Blast Announcement Settings Defining Criteria for Redundant Announcements Enabling and Defining Announcement Engine Settings Defining Employee Subscription Options Defining Blast Announcement Settings Project administrators may define basic announcement settings including SMTP outgoing mail server settings, reply names, and reply addresses in the Announcement page of ServiceWise work projects. Project administrators may define the name and address of the sender of the . All replies to the are automatically directed to the administrator-defined reply address. For example, announcement blast messages may be sent to employees fromabc Software Newsat the addresssales@abcsoftware.com. To define blast announcement mail server: 1Enter a name in the Reply Name field of the Announcement page. For example,abc Software News 2Enter a name in the Reply Name field of the Announcement page. For example,sales@abcsoftware.com. 3Define the name of the SMTP server in the Outgoing Mail (SMTP) Server Name field. Project administrators may enter the mail server name or IP address. 4If the mail server requires authentication, select the My Mail Server Requires Authentication check box and enter the user name and password. The account information can be either a domain user account or the server computer account with privileges of using the outgoing mail server service Defining Criteria for Redundant Announcements Project administrators may define rules that ensure that employees to not receive multiple copies of the same blast announcement with a set time period. Depending on the blast announcement rules defined by project members in the ServiceWise clients, employees may be schedule to receive announcements based on several different triggers. The Time Period (Days) control in the Announcement page enable administrators to ensure that the same is not delivered during the time period assigned by the administrator Enabling and Defining Announcement Engine Settings The Announcement Engine checks announcement rules on regular, administrator-defined intervals and checks to see if a announcement rules has been triggered. The ServiceWise Announcement Engine is an optional feature that requires a separate purchase from TechExcel. To define announcement engine settings: 1Select the Enable Announcement Engine for Handling Scheduled Announcements check box. The announcement engine must be enabled for project team member to send blast announcements. 2Define the interval between blasts in the Announcement Engine Interval Time (in Minutes) control. Project administrators may define interval settings for numbers between 1 and 30. Page 112 of 145

113 Defining Employee Subscription Options Project administrators may enable project members to unsubscribe to future announcements. To define employee subscription options: 1Select the Enable Employees to Define Announcement Preference check box. 2Select an option from the Stop Method dropdown list. Project members may use one of two methods to unsubscribe: The Via FormWise subscription forms option enables employees to employees subscribe and unsubscribe to your lists. The Via reply with keywords option enables employees to unsubscribe by replying to the announcement with any of the keywords specified below in the e- mail subject. 3Define the keyword in the Keyword in Subject field. Administrators may define the keyword that must be in the subject line of the reply to cancel the subscription. For example,unsubscribeorremove. 4To use the default message, click the Default button. If the Default button is selected, the Define the Message field displays the message: If you would like to be removed from the mailing list, simply reply to this with word 'REMOVE' in the subject. 5Define the Message Specify the instructional message to be displayed in the . This message should instruct employees how to unsubscribe from the list and will be automatically included in mass s sent to employees Defining Dynamic FAQs TechExcel dynamic FAQs enable administrators to search for and dynamically link related knowledge topics to FAQ categories, and enable project members to access project FAQs. The FAQ list page may customized to display FAQ categories with knowledge topic titles and summaries, and the links to the knowledge topic detail pages. Print and is enabled in the detail page. TechExcel Dynamic FAQ is fully customizable, enables project teams to customize the company header and logo; a predefined theme may be used to define web styles, let you define font, size, color, and image for any web elements. TechExcel Dynamic FAQ can be fully integrated with the Employee TechExcel Employee Web Portal. One or more FAQs can be included in the Employee Web Portal, with Knowledge Portal. Employees may access the FAQ List page by a FAQ link from sent to them, or a link in the company site Enabling and Defining Dynamic FAQ Server Settings To define dynamic FAQ server settings: 1Select the Enable Dynamic FAQ Feature check box. 2Enter a name in the Reply Name field of the Announcement page. For example,abc Software News 3Enter a name in the Reply Name field of the Announcement page. For example,help@abcsoftware.com. 4Define the outgoing mail server in the Outgoing Mail (SMTP) Server field. Administrators may enter the mail server name or IP address. 5If the mail server requires authentication, select the My Mail Server Requires Authentication check box and enter the user name and password. The account information can be either a domain user account or the server computer account with privileges of using the outgoing mail server service Customizing the Knowledge View Knowledge view pages are displayed in the Knowledge Detail window of the ServiceWise client applications: the Description page, the History page, the Resolution page. These pages enable project members to define detailed information for a single knowledge item. Administrator-defined customizations to the Knowledge view in the ServiceWise clients is relatively limited: administrators may customize the titles of all detail pages and the field labels for all data-entry controls. The Description page tracks general information about a knowledge item including its title, description, and identifying keywords. The History page is used for knowledge document version control. The History page will display all versions of a selected document as well as a project members notes for that revision. The Resolution page is used strictly for knowledge topics and is used to describe a common knowledge topic in more detail. Only two controls may be customized: the Products control and the Modules control in the Description page. Project-level customization tasks include: Customizing the Description Page Customizing the History Page Customizing the Resolution Page Customizing the Description Page The Description page tracks general information about a knowledge item. Administrators may make only limited customizations to most of the controls displayed in the Description page: administrators may customize the titles of all detail pages and the field labels for all data-entry controls. The Products control and the Modules controls may be customized. Administrators may Customize the field label used to identify the data tracked in the control. Define the control as visible or invisible in the project. Define the values displayed as options in the dropdown list control by linking the control to an incident property or by manually defining the values. The values displayed in the dropdown list may be linked to one of five different fields or manually define the values displayed in the control: Product Line Priority Database Priority Response Time Administrators may optionally select the {None} option and manually define the values displayed in the control Customizing the History Page The History page is used for knowledge document version control. The History page will display all versions of a selected document as well as a project members notes for that revision. Administrators may customize the page title and column field labels. No other customizations may be made to this page Customizing the Resolution Page The Resolution page is used strictly for knowledge topics and is used to describe a common knowledge topic in more detail. Administrators may customize the page title and control field labels. No other customizations may be made to this page Managing ServiceWise-RightAnswers Integration Project administrators may integrate the ServiceWise Knowledge Portal with RightAnswers, a knowledge-driven self service application for managing documents. TechExcel ServiceWise-RightAnswers integration may be configured in the External Knowledge Integration page of the Knowledge view page in the ServiceWise Admin client. Page 113 of 145

114 Figure 18-1: External Knowledge Integration Page To enable and configure third-party knowledge portal integration: 1Enable support for external knowledge bases in the Optional Features page of the General Project Settings folder. For step-by-step instructions see See Managing Optional Project Features on page Select the Integrated with RightAnswes option from the Enable KnowledgeWise External Knowledge dropdown list. The The Enable KnowledgeWise External Knowledge dropdown list. displays two options: No Support for External Knowledge Integrated with RightAnswer. 3Define path to the RightAnswers login in the Web Login Path edit box control: c:\inetpub\wwwroot folder. 4Select an option from the Knowledge Access Options dropdown list. The Knowledge Access Options dropdown list displays two options: Both Internal Knowledge and External Knowledge External Knowledge Only 5Define the access code in the Knowledge Access Code edit box control. 6Define team member and end user login name and password in the appropriate controls. Team Member Password Team Member Login End User Password End User Login 7Go to Knowledge Portal in the Employee Web Portal. 8Choose Standard Knowledge Portal Option. Make sure External Knowledge Integration is checked. The External Knowledge Integration tab is displayed Backing up the Document Files HTML links, announcements, and topics are stored in the TechExcel ServiceWise database. All files in the Documents and Attachments folders however are stored on the ServiceWise Document Server. TechExcel recommends backing up this document server on a regular basis. The default directory for document storage on the ServiceWise Document Server is specified during installation of the ServiceWise Document Server. A sample path could be: C:\Program Files\Techexcel\ServiceWiseDoc\P# Where # is the project ID Managing ServiceWise Autorecommendations KnowledgeWise increases the accessibility of the knowledge items stored in project knoweldge bases with ServiceWise Autorecommendation. ServiceWise may recommend knowledge items to ServiceWise users (employees and project members) based on three different factors: the expert points assigned to userdefined keywords (expert keywords) that are assigned to knowledge items, user-defined relevance rankings (employee keyword ranking pointsandteam member keyword ranking points), and system-generatedkeyword clicking points. ServiceWise weighs the relative weight of these three factors to determine which knowledge items are recommended to project members and cusotmers based on the keywords they used for their knowledge search. Administrators may configure ServiceWise Auto Recommendation engine to determine the relative weight given to each factor. Auto recommendation is an optional feature that must be enabled by a project administrator in the ServiceWise Admin client. ServiceWise may automatically recommend knowledge items to employees and to project members. Knowledge items may be recommended to employees searching for knowledge items in the Employee Web Portal. Knowledge items may be recommended to project members submitting incidents through . The relevance of knowledge items to knowledge searches is based on the keywords that the employee or project member defines for that search. Three factors determine the relevance of those keywords to knowledge items: Expert keywords and expert keyword points Employee and team member keyword ranking points Keyword clicking points Expert keywords and expert keyword points In the ServiceWise, project members (experts), may assign expert keywords to project knowledge items and the relative weight of each expert keyword (expert points). Every expert keyword is assigned expert points a value between 0 and 100 which determine how heavily an expert keyword is weighed by the ServiceWise Search Engine in autorecommendation processes. A high score indicates that the expert keyword is highly relevant to the subject matter of the document. A expert point weight of 0 indicates that the keyword is completely irrelevant to the information in the knowledge item. An expert point weight of 100 indicates that the keyword is extremely relevant to the information in the knowledge item. The ServiceWise Search Engine may or may not weigh the expert point values that users assign to keywords. Project administrators may determine how heavily the expert points assigned to expert keywords are weighed by assigning a weight to user-defined expert points. A high score indicates that the expert points assigned to a keyword are an important factor when determining which knowledge items to recommend to a user. A low score indicates that other factors (for example, keyword ranking points or keyword clicking points) are more important than expert points, and that the expert points assigned to a keyword is less significant to these other values Employee and team member keyword ranking points Keyword ranking pointsare based on feedback provided by users when a particular knowledge item is recommended to them. Project members and employees may rank the relative usefulness of the item returned by assigning keyword ranking points (a value between 0-100) to the knowledge item. Every time a keyword is recommended to a project member or employee that user has the opportunity to rank the knowledge item based on its relevance to their search. ServiceWise compares the keyword ranking points assigned to the knowledge item against the keywords used in the search and adjusts the keyword ranking points assigned to the keyword for the docuemnt accordingly. Users may assign keyword ranking points a value between 0 and 100 to keywords that determine how heavily the keyword is weighed by the ServiceWise Search Engine. A high score indicates that the keyword is relevant to the information contained in the document. A keyword ranking point weight of 0 indicates that the keyword is completely irrelevant to the information in the knowledge item. An keyword ranking point weight of 100 indicates that the keyword is extremely relevant to the information in the knowledge item. The ServiceWise Search Engine may or may not weigh the ranking point highly when determining the relevance of knowledge items for each keyword. Administrators may how important keyword ranking points when they define employee ranking rules and team member ranking rules in the Auto Recommendation page Keyword clicking points Keyword clicking pointsare based on the user-defined queries to the project knowledge base. Commonly entered keywords are more highly ranked than rarer keywords. Project administrators may define how the ServiceWise system weighs each of these factors when it recommends a knowledge item. Using the slidebar controls in the Auto Recommend Setting page, administrators may assign different weights to each factor. Page 114 of 145

115 Expert points may be weighed on a scale of 0 to 100. If a weight of 0 is selected the points assigned to expert keywords are not taken into account. If the a weight of 100 is assigned to expert points, then these ranking are very important. Keyword ranking points may be weighed on a scale of 0 to 100. ServiceWise tracks all of the keywords that are used locate knowledge items and filters outnoise words (common prepositions, articles, and conjunctions:to,the,and) and saves only meaningful keywords Defining Expert Keyword Points Weights Expert keywordsare assigned to knowledge items by ServiceWise project members in the ServiceWise clients. Each keyword is assigned a weight (1-100). Project members may also enable each keyword to be used to auto-recommend the knowledge item by selecting the Auto Suggest check box. Expert points may be weighed on a scale of 0 to 100. If a weight of 0 is selected the points assigned to expert keywords are not taken into account. If the a weight of 100 is assigned to expert points, then these ranking are very important. To define the relative weight assigned to user-defined expert points, use the slidebar control to define a number between 0 and 100. A weight of 0 indicates that expert points assigned to a keyword are not taken into account at all when ServiceWise recommends a knowledge item. A weight of 100 indicates that expert points assigned to a keyword are a determining factor when ServiceWise recommends a knowledge item Defining Employee Ranking Rules Employee ranking rules determine which knowledge items are recommended to employees based on the keywords that they use to search the knowledge base. Employee ranking rules are based on two factors: keyword ranking points and keyword clicking points. Keyword ranking pointsare based on feedback provided by users when a particular knowledge item is recommended to them. Project members and employees may rank the relative usefulness of the item returned. Administrators may weigh project member and employee keyword ranking points differently in ServiceWise projects. Keyword clicking pointsare automatically calculated by ServiceWise based on the frequency with which a keyword is used to query the knowledge base. Common keywords are assigned more keyword clicking points than rare keywords. Project administrators may determine the relative weight that ServiceWise assigns to keyword ranking points and keyword clicking points. To define employee ranking rules: 1Enable support for auto recommendation of knowledge links for incident submission through . In the Employee Ranking Rule area define the rules that ServiceWise uses to recommend knowledge items to employees. 2Define keyword ranking points weight for project members. Keyword ranking points are based on feedback provided by users when a particular knowledge item is recommended to them. Project members and employees may rank the relative usefulness of the item returned. A weight of 0 indicates that employee-defined keyword ranking points are not taken into account at all when ServiceWise recommends a knowledge item. A weight of 0 indicates that employee-defined keyword ranking points are a determining factor when ServiceWise recommends a knowledge item. 3Define search results keyword clicking points weight. Keyword clicking points are based on the user-defined queries to the project knowledge base. Commonly entered keywords are more highly ranked than rarer keywords. A weight of 0 indicates that employee-defined keyword ranking points are not taken into account at all when ServiceWise recommends a knowledge item. A weight of 0 indicates that employee-defined keyword ranking points are a determining factor when ServiceWise recommends a knowledge item. 4Define the number of clicks required for a keyword to receive a knowledge click point. Administrators may define the minimum number of clicks for a keyword to receive knowledge click points. 5Define search engine keywords match points Defining Project Member Ranking Rules Project member ranking rules determine which knowledge items are recommended to employees based on the keywords that they use in their knowledge search. Ranking rules are based on two factors: keyword ranking points and keyword clicking points. Administrators may determine the relative weight assigned to each of these factors when ServiceWise recommends knowledge items to cusotmers. Keyword ranking pointsare based on feedback provided by users when a particular knowledge item is recommended to them. Project members and employees may rank the relative usefulness of the item returned. Administrators may weigh project member and employee keyword ranking points differently in ServiceWise projects. Keyword clicking pointsare automatically calculated by ServiceWise based on the frequency with which a keyword is used to query the knowledge base. Common keywords are assigned more keyword clicking points than rare keywords. To define project member ranking rules: 1Enable support for auto recommendation of knowledge links for incident submission through . In the Employee Ranking Rule area define the rules that ServiceWise uses to recommend knowledge items to employees. 2Define keyword ranking points weight for project members. Keyword ranking points are based on feedback provided by users when a particular knowledge item is recommended to them. Project members and employees may rank the relative usefulness of the item returned. A weight of 0 indicates that employee-defined keyword ranking points are not taken into account at all when ServiceWise recommends a knowledge item. A weight of 0 indicates that employee-defined keyword ranking points are a determining factor when ServiceWise recommends a knowledge item. 3Define search results keyword clicking points weight. Keyword clicking points are based on the user-defined queries to the project knowledge base. Commonly entered keywords are more highly ranked than rarer keywords. A weight of 0 indicates that employee-defined keyword ranking points are not taken into account at all when ServiceWise recommends a knowledge item. A weight of 0 indicates that employee-defined keyword ranking points are a determining factor when ServiceWise recommends a knowledge item. 4Define the number of clicks required for a keyword to receive a knowledge click point. Administrators may define the minimum number of clicks for a keyword to receive knowledge click points. 5Define search engine keywords match points Defining Search Engine Keyword Matching Points Keyword matching pointsdefine the relative weight that is given to keywords located in the title or summary of a knowledge item versus keywords located in the body of the document or topic. Project administrators may define keyword matching points in the the Auto Recommendation Setting page. To weigh keywords in the title or summary of a knowledge item more highly than those in the body of a knowledge item, assign a higher number in the Title and Summary Keyword Match Points control. To weigh keywords in the body of a knowledge item more highly than those in the title or summary of a knowledge item, assign a higher number in the Content Document Keyword Match Points control. To define Search Engine keyword matching points: 1Define title and summary keyword match points. 2Define content document match points. Chapter 19 Service Agreement Administration 19 Chapter19 -- Service Agreement Administration In TechExcel ServiceWise, service level agreements define the levels of service that are offered to company employees. Support organizations may define many different levels of service based on employee account types, incident types, and supported assets. In this chapter: Understanding ServiceWise Service Agreements Administering Service Agreement General Properties Administering Support Schedules Administering Service Agreement Statuses Understanding ServiceWise Service Agreements Page 115 of 145

116 19.1 Understanding ServiceWise Service Agreements TechExcel ServiceWise offers a complete solution for managinginternalhelp desk support the support services that a business offers to its employees. Using the service agreement manager, project members may define, manage, and track service level agreements in ServiceWise projects. Each service level agreement defines a level of support services that may be offered to the company employees. Different employees may receive different levels of service guaranteed response times, resolve times, and support schedules based on their account type, the incident type, or the associated asset. Thesupport scheduledefines the dates, days, and hours during which support services are contracted to the employee. Theresponse timedefines the time in which a incident submitted by an employee must be responded to by the support team. Theresolve timedefines the time in which a incident submitted by an employee must be resolved by the support team. ServiceWise service agreement support is an optional ServiceWise feature Understanding ServiceWise SLA Management Support engineers may manage and track employee service level commitments using administrator-defined service templates, event service templates, and service agreement templates. Service-level agreement templates enable project administrators to define business rules that determine how particular incidents are managed and tracked based on the incident type or the employee. The Service Agreement Manager tracks all service plan charges, generates appropriate invoices, and tracks all payment and renewal history. Using the Service Agreement Manager each employee may be assigned one or multiple service agreements. Service plan pricing can be a fixed fee per incident, annual contracts, or may include a base level of support with additional service charges per hour or per incident. Guaranteed response time can be defined for each service plan, with incidents automatically escalated if the time is exceeded. Every incident submitted to a TechExcel ServiceWise project is assigned a service plan that covers the support cost of the incident based incident properties. Based on the incident properties, TechExcel ServiceWise can automatically select a valid service level agreement and decide if support is covered. A default service agreement can also be specified to cover incidents that do not match predefined conditions. Service agreement templates In ServiceWise, every service agreement is based on an administrator-defined service agreement template.service-level agreement templatesrepresent the support plan that exists between an employee and the support organization. Aservice-level agreement templateis a cluster of service agreement settings a support schedule, response time, resolve time, and other settings that enable project members to quickly apply the appropriate service level agreement to each support incident. Cost calculation and invoicing Every administrator-defined service agreement template defines not only level of service promised to the employee the support schedule, response time and resolve time, but also predefined support cost calculation and corresponding invoicing methods. Employees may be assigned multiple service agreements across multiple product lines. Note:TechExcel ServiceWise features the same service agreement tools available in the TechExcel CustomerWise Suite of customer management tools including service agreement management, cost calculation, and invoicing. Although most businesses do not invoice their own employees for support services, ServiceWise provides businesses with the flexibility to manage and track support services to suit their business model Understanding ServiceWise Service Agreement Configuration In ServiceWise, all service agreement configurations are encapsulated in administrator-defined service agreement templates. Aservice-level agreement templateis a cluster of service agreement settings a support schedule, response time, resolve time, and other settings that enable project members to quickly apply the appropriate service level agreement to each support incident. But to create service agreement templates, a project administrator mustfirstdefine the appropriate time tracking and service settings the work type and service template objects, and one or more company support schedule, service type, and service agreement status objects. Every service agreement template is built on a foundation of time tracking and service management configurations. The following business objects must be defined before the administrator can define ServiceWise service agreement templates: Service templatesrepresent a service that is performed for an employee. Each service template is a cluster of administrator-defined configurations: a work type, cost method, sales method, and time-tracking method. Every service templates may be time-related or non-time-related. Shipping and payment method settingsdefine how the services mandated by the service level agreement are to be shipped and charged to the employee. For more information and step-by-step instructions for creating support schedules see See Administering Support Schedules. Theemployee support scheduledefines the dates, days, and hours during which support services are contracted to the employee. For more information and step-by-step instructions for creating support schedules see See Administering Support Schedules. Theservice agreement statusof a service agreement indicates the current status of that service agreement and may trigger an administrator-defined action. Every service agreement template is defined by a default service agreement status. For more information and step-by-step instructions for creating support schedules see See Administering Service Agreement Statuses. All service agreement configurations are built on a foundation of time tracking and service management configurations. The project administrator must also enable service agreement support in the project and define account type-based access controls. Service agreement is an optional ServiceWise feature. For more information and step-by-step instructions for creating support schedules see See Administering Service Agreement General Properties. Project administrators may define service agreement templates in the Service Agreement folder of the ServiceWise Admin client Administering Service Agreement General Properties Service agreement templates and service agreement management is an optional feature in TechExcel ServiceWise. Project administrators may enable service agreement support in ServiceWise projects and grant service agreement privileges to project members in the General Settings page of the Service Agreement folder of the ServiceWise Admin client. If an administrator enables service agreement management in a project, two changes are made to the TechExcel ServiceWise client applications: The Service Tracking page is displayed in the Incident view of the ServiceWise clients. Whenever a new incident is submitted to the project, a valid and active service agreement plan is automatically selected and assigned to that incident. Note:All service agreement settings are specifically defined in each work project. The Service Agreement folder is not displayed in the Admin tree window of employee base projects Service agreement administrative tasks include: Enabling Service Agreement Support Defining Service Agreement Access Controls Enabling Service Agreement Support To enable service agreements in a ServiceWise support project, project administrators must select the Enable Service Agreement Support check box in General Settings page of the Service Agreement folder Defining Service Agreement Access Controls The ability of ServiceWise project members to create, manage, and track service agreements in ServiceWise projects is based on account type-based access privileges. Project administrators may determine which project members are eligible to view, assign, and edit service agreements by granting service agreement privileges to project account types in the General Settings page of the Service Agreement folder in the ServiceWise Admin client. Service agreement privileges are granted to project members in each ServiceWise project. Each ServiceWise project is characterized by a unique set of access control settings. Project administrators may grant six different privileges to each account type in their project. Page 116 of 145

117 the Service Agreement folder Defining Service Agreement Access Controls The ability of ServiceWise project members to create, manage, and track service agreements in ServiceWise projects is based on account type-based access privileges. Project administrators may determine which project members are eligible to view, assign, and edit service agreements by granting service agreement privileges to project account types in the General Settings page of the Service Agreement folder in the ServiceWise Admin client. Service agreement privileges are granted to project members in each ServiceWise project. Each ServiceWise project is characterized by a unique set of access control settings. Project administrators may grant six different privileges to each account type in their project. Table 19-1: Service Template Privileges 19.3 Administering Support Schedules TechExcel ServiceWise enables project administrators to define multiple support schedules within each work project to identify the different levels of service that may be offered to employees based on their support plan. Asupport scheduledefines the dates, days, and times that support services are offered to employees. Every service-level agreement is defined by a single support schedule. A support schedule is defined by time zone, support time, and holiday settings: Time zonesettings define the location of the team members responsible for delivering services to employees. The time zone selected determines how the dates, days, and business hours defined in the support schedule are represented to the employee. Support timesrepresent companybusiness hours, the days and time periods during which employees may expect services based on their service agreement. Schedule holidaysrepresent the days and time periods during which employeescannotexpect services based on their service agreement. Project administrators may create, edit, and delete support schedules in the Company Support Schedule page of the Service Agreement folder in the ServiceWise Admin client. Support schedule administrative tasks include: Adding Support Schedules Deleting Support Schedules Defining Support Schedule Support Times Managing Support Schedule Holidays Adding Support Schedules Project administrators may create support schedules in the General tab of the Company Support Schedule page of the ServiceWise Admin client. To add a support schedule: 1Click the Add New button in the General tab of the Company Support Schedule page. The Add New Support Schedule dialog box appears. 2Define the name, time zone, and brief description for the support schedule. 3Click the OK button. The Add New Support Schedule dialog box closes Deleting Support Schedules To delete a support schedule: 1Select a support schedule in the Support Schedules list of the Company Support Schedule page in the Service Agreement folder. 2Click the Delete button. A warning dialog box appears. 3Click the Yes button. The support schedule is deleted Defining Support Schedule Support Times Support times represent companybusiness hours, the days and time periods during which employees may expect services based on their service agreement. The support periods and break periods are expressed in the hours for the time zone that is applicable to the support schedule. To define support schedule support times: 1Select a support schedule in the Support Schedules list of the Company Support Schedule page in the Service Agreement folder. 2Select a day of the week in the Support Time tab. 3Click the Edit button. The Support Schedule Settings dialog box appears. 4Select an option from the Support Schedule Settings dropdown list. The Support Schedule Settings dropdown list displays three options: The Limited Hours Support on this Day option The No Support on this Day option The 24 Hours Support on this Day option 5Select the starting and ending times in Work Period area. 6Define the break in the Break area. 7 Optional:To apply the current settings to every day of the week, select the Apply these Settings to other Working Days check box. 8Click the OK button. Page The Support Schedule Settings dialog box closes. 117 of Managing Support Schedule Holidays Schedule holidays represent the days and time periods during which employees cannot expect services based on their service agreement. Project administrators may define the name, date, and the amount of time off for the holiday in the Holidays tab of the Company Support Schedule page in the Service Agreement

118 8Click the OK button. The Support Schedule Settings dialog box closes Managing Support Schedule Holidays Schedule holidays represent the days and time periods during which employees cannot expect services based on their service agreement. Project administrators may define the name, date, and the amount of time off for the holiday in the Holidays tab of the Company Support Schedule page in the Service Agreement folder in the ServiceWise Admin client. To add a holiday: 1Select a support schedule in the Support Schedules list of the Company Support Schedule page in the Service Agreement folder. 2Click the Add button in the Holiday tab. The Support Holiday Settings dialog box appears. 3Select an option from the Support Holiday Settings dropdown list. 4Define the holiday name, date, and the number of days off for the holiday. 5 Optional:To define the number of hours off for partial holidays, select the beginning and ending times for the work day in the Start Time and End Time dropdown list Administering Service Agreement Statuses Aservice agreement statusfacilitates the management of support incidents by defining the applicability of a service agreement to the support incident and defining a unique service agreement message. At all times during incident workflow, the service agreement that is applied to a support incident is defined by a service agreement status. Support engineers may change the service agreement status of a service agreement to enable or disable project service agreement management tools time tracking and cost tracking and to communicate key information to the employee. Every service agreement status is defined by two properties: an activity setting and a service agreement message: Activity settingsdetermine whether a service agreement is active or inactive at any given time. Every service agreement status is either an active status or an inactive status. Service agreement messagesprovide employees and support engineers with information about the current status of the service agreement Project administrators may define any number of service agreement statuses in the Service Agreement Status page of the Service Agreement folder. Examples of service agreement statuses might include: Active Cancel-Per Employee Lost in Transit Not Purchased Renewal Sent/NOT Active Returned Product Service agreement status administrative tasks include: Adding Service Agreement Statuses Activating or Deactivating Service Agreement Statuses Defining Service Agreement Status Messages Adding Service Agreement Statuses Project administrators may create, edit, and define service agreement statuses in the Service Agreement Status page in the Service Agreement folder. Project administrators may define any number of service agreement statuses in a ServiceWise project. At all times during the incident life cycle, the associated service agreement is defined by its service agreement status. To add a service agreement status: 1Click the Add button in the Service Agreement Status page of the Service Agreement folder. The Status dialog box appears. 2Define the name of the status. 3Click the OK button. The Status dialog box closes Activating or Deactivating Service Agreement Statuses Project administrators may define any number of service agreement statuses to define project service agreements. Each service agreement status is defined by an activity status active or inactive and, optionally, two administrator-defined service agreement messages: an employee message and a support engineer message. To activate or deactivate a agreement status: 1Select a service agreement status in the Status list of the Service Agreement Status page. 2Select the General tab. 3 Optional:To activate or deactivate the service agreement in the service agreement status select to deselect the Active On This Status check box in the General tab. The Active On This Status check box is a modal control. If the check box is selected, the service agreement status is an active status and a service agreement isenforcedwhenever a service agreement is in the service agreement status. If the check box is not selected, the service agreement status is an inactive status and a service agreement isnot enforcedwhenever a service agreement is in the service agreement status Defining Service Agreement Status Messages In ServiceWise projects, service agreement status messages may be displayed in the ServiceWise client and Employee Web Portal to provide support engineers and employees with information about the current status of each service agreement. Project administrators may define any number of service agreement statuses to define project service agreements. Each service agreement status is defined by an activity status active or inactive and, optionally, two administrator-defined service agreement messages: an employee message and a support engineer message. Theemployee service agreement messageis displayed in the Employee Web Portal and provides the employee with information about the current status of their service agreement and support incident. The employee service agreement message supports HTML markup tags. Thesupport engineer messageis displayed in the ServiceWise client and provides the project member with information about the current status of their service agreement and support incident. Service agreement messages are an optional feature that may or may not be displayed in the Employee Web Portal or ServiceWise client. To define service agreement status messages: 1Select a service agreement status in the Status list of the Service Agreement Status page. 2Select the Action tab. 3 Optional:To display the administrator-defined service agreement status messages to the employee and support engineer, select the Display Message to Employee and Support Engineer check box. Both messages are either hidden or displayed. 4 Optional:To define the service agreement message that is displayed to employees in the Employee Web Portal, enter a message in the Employee Message control. The Employee Message control support HTML markup tags. Optional: To define the service agreement message that is displayed to support members in the ServiceWise client,enter a message in the Support Engineer control Adding Service Agreement Statuses Project administrators may create, edit, and define service agreement statuses in the Service Agreement Status page in the Service Agreement folder. Project administrators may define any number of service agreement statuses in a ServiceWise project. At all times during the incident life cycle, the associated service agreement is defined by its service agreement status. To add a service agreement status: 1Click the Add button in the Service Agreement Status page of the Service Agreement folder. The Status dialog box appears. 2Define the name of the status. 3Click the OK button. Page 118 of 145

119 The Status dialog box closes Activating or Deactivating Service Agreement Statuses Project administrators may define any number of service agreement statuses to define project service agreements. Each service agreement status is defined by an activity status active or inactive and, optionally, two administrator-defined service agreement messages: an employee message and a support engineer message. To activate or deactivate a agreement status: 1Select a service agreement status in the Status list of the Service Agreement Status page. 2Select the General tab. 3 Optional:To activate or deactivate the service agreement in the service agreement status select to deselect the Active On This Status check box in the General tab. The Active On This Status check box is a modal control. If the check box is selected, the service agreement status is an active status and a service agreement isenforcedwhenever a service agreement is in the service agreement status. If the check box is not selected, the service agreement status is an inactive status and a service agreement isnot enforcedwhenever a service agreement is in the service agreement status Defining Service Agreement Status Messages In ServiceWise projects, service agreement status messages may be displayed in the ServiceWise client and Employee Web Portal to provide support engineers and employees with information about the current status of each service agreement. Project administrators may define any number of service agreement statuses to define project service agreements. Each service agreement status is defined by an activity status active or inactive and, optionally, two administrator-defined service agreement messages: an employee message and a support engineer message. Theemployee service agreement messageis displayed in the Employee Web Portal and provides the employee with information about the current status of their service agreement and support incident. The employee service agreement message supports HTML markup tags. Thesupport engineer messageis displayed in the ServiceWise client and provides the project member with information about the current status of their service agreement and support incident. Service agreement messages are an optional feature that may or may not be displayed in the Employee Web Portal or ServiceWise client. To define service agreement status messages: 1Select a service agreement status in the Status list of the Service Agreement Status page. 2Select the Action tab. 3 Optional:To display the administrator-defined service agreement status messages to the employee and support engineer, select the Display Message to Employee and Support Engineer check box. Both messages are either hidden or displayed. 4 Optional:To define the service agreement message that is displayed to employees in the Employee Web Portal, enter a message in the Employee Message control. The Employee Message control support HTML markup tags. Optional:To define the service agreement message that is displayed to support members in the ServiceWise client,enter a message in the Support Engineer control Administering Service Agreement Templates Aservice-level agreement templateis a cluster of service agreement settings a support schedule, response time, resolve time, service agreement status, and other settings that define the level of service that is to be applied to an employee or incident Different levels of service may be promised to that employee based on many different factors including the employee s role in the company (employee type), the asset type, or the incident type. Employee-based service level agreements define the level of service that is promised to an employee for every incident associated with that employee. Incident-based service level agreements define the level of service that is promised to an employee based on the incident type. Asset-based service level agreements define the level of service that is promised to an employee based on the asset type. Every service level agreement is defined by five properties: the service agreement type, support schedule, response time, resolve time, and default status. Project administrators may optionally define multiple advanced service agreement settings for each service agreement template including cost calculation and pricing, renewal, time tracking, invoicing, and credit items. Project administrators may create, delete, and define service agreement templates in the Service Agreement Template page of the Service Agreement folder in the ServiceWise Admin client. Service agreement template administrative tasks include: Creating Service Agreement Templates Deleting Service Agreement Templates Defining General Service Agreement Template Settings Administering Response and Resolve Times Enabling Multiple Response/Resolve Times Defining Default Response/Resolve Times Defining Service Agreement Template Response/Resolve Times Administering Service Agreement Application Rules Defining Service Agreement Application Rules Creating Service Agreement Templates Aservice-level agreement templateis a cluster of service agreement settings a support schedule, response time, resolve time, service agreement status, and other settings that define the level of service that is promise to an employee. Service level agreements may be applied to employees or on an incident-by-incident basis. Every service agreement template is defined by five basic properties. Theservice agreement typedetermines how support costs are calculated for the support plan. Thesupport scheduledefines the dates, days, and hours during which support services are contracted to the employee. Theresponse timedefines the time in which a incident submitted by an employee must be responded to by the support team. Theresolve timedefines the time in which a incident submitted by an employee must be resolved by the support team. Thedefault service agreement statusdefines the default service a agreement status of the support plan. Project administrators may create, delete, and define service agreement templates in the Service Agreement Template page of the Service Agreement folder in the ServiceWise Admin client Service agreement type Every service agreement template is defined by itsservice agreement type. The service agreement type determines how the costs of support services are calculated for that support plan. A service agreement template may be assigned one of four different service agreement types: Annual Service Agreement: The Annual Service Agreement service agreement type represents plans that are used for software trial periods and free support. Per Incident Service Agreement:The Per Incident Service Agreement service agreement type represents plans that are based on a per incident basis. Free Service Agreement: The Free Service Agreement service agreement type represents plans that are based on annual support arrangements. Annual Service Agreement with Asset Integration: The Annual Service Agreement with Asset Integration service agreement type represents plans that are based on annual support arrangements directly related to the assets purchased or owned by a company, including hardware and software licenses. Requires the purchase of TechExcel AssetWise. To create service agreement templates: 1Click the New button in the Service Agreement Template page of the Service Agreement folder. The New Service Plan dialog box appears. 2Define a unique name for the service agreement template in the Name control. 3Define a brief description of the service agreement template in the Description control. 4Select a service agreement type option from the Support Type dropdown list control. Theservice agreement typedetermines how support costs are calculated for the support plan. Page 119 of 145

120 The Support Type dropdown list displays four options: Annual Service Agreement Per Incident Service Agreement Free Service Agreement Annual Service Agreement with Asset Integration. The option selected determines which data-entry co Chapter 20 Professional Services Administration 20 Chapter20 -- Professional Services Administration This chapter describes administrative tasks for the TechExcel advanced time tracking and professional services management features. These feature require the separate purchase of the Service Agreement Manager. In this chapter: Understanding ServiceWise Professional Services Management Enabling General Time and Service Management Features Administering Standard Professional Services Management Administering Advanced Time and Service Management Administering Service Templates Administering Service Template Work Codes Administering Service Template Volume Pricing Administering Event Service Templates 20.1 Understanding ServiceWise Professional Services Management The system pages displayed in the Time/Service Management folder enable project administrators to define time tracking and professional service management features in ServiceWise projects. Note:The majority of these settings are specific to the current work project. Only the Work Type page and Service Template pages are stored in and are available in the base project Understanding Standard and Advanced Services Time and service management features fall into two categories: standard time and service management and Advanced time and service management. Four standard time/service management pages in the Time/Service Management folder: The General Setting system page The Work Type system page The Standard Rate system page The Privileges system page Advanced Time Tracking and Service Management pages enable administrators to configure advanced time tracking and service management features. Five additional Advanced Time Tracking and Service Management pages may also be displayed in Time/Service Management folder. Work Order Budget Control Service Template Access Control Event Service Template Advanced professional service management functions require the separate purchase of the Service Agreement Manager. The Advanced Time Tracking and Service Management features require the purchase of the Service Agreement Module. Project administrators may also enable advanced time tracking and service management features in the Optional Features page Enabling General Time and Service Management Features Project administrators may enable professional services management settings in the General Setting page of the Time/Service folder. General time and service management administrative tasks include: Enabling Professional Services Time Tracking Enabling Professional Services Cost Tracking Enabling Professional Services Sales Tracking Enabling Service Template Support Enabling Time Usage Recording Displaying the Billable Check Box to Employees Enabling Professional Services Time Tracking ServiceWise professional service time tracking enables businesses to track the time that is required for support engineers to process support incidents. To enable professional service time tracking, select the Enable Time Tracking check box in the General Setting page Enabling Professional Services Cost Tracking ServiceWise professional service cost tracking enables businesses to track the outgoing costs that are paid to process support incidents. To enable cost tracking, select the Enable Cost Tracking check box in the General Setting page Enabling Professional Services Sales Tracking ServiceWise professional service sales tracking enables businesses to track the revenue generated through support incidents. To enable sales tracking, select the Enable Sales Tracking check box in the General Setting page Enabling Service Template Support In ServiceWise, service templates define the methods used to track the time, cost, and price of support services. To enable support service templates, select the Support Service Templates check box in the General Setting page. Service templates are only needed if the company needs to track the time spent, the cost, or the price of individual support services. For more information see See Administering Service Templates on page Enabling Time Usage Recording To enable time usage recording, select the Record Time Usage when Incident is Forwarded or Closed check box Displaying the Billable Check Box to Employees To display the Billable check box to employees, select the Enable Time Tracking check box Administering Standard Professional Services Management ServiceWise enables businesses to measure and track the cost of the support services it offers to employees. Cost calculation controls may be used to bill employees for support services. Businesses may track the cost of support services based on the support services offered to company employees or on the cost of the technician that performs those services. The hourly rate of support services may be determined by three primary factors: the work type, the account type of the technician providing the service, or the user account of the Page 120 of 145

121 technician providing the service. Awork typeidentifies a specific support service and defines the default hourly rate that the business charges for that service. Anaccount type hourly ratedefines the default hourly rate that a business charges for a work type performed by a project member that belongs to a specific account type. Anproject member hourly ratedefines the default hourly rate that a business charges for a work type performed by a specific project member. Work type and standard hourly rate administration tasks include: Adding Work Types Editing Work Types Deleting Work Types Defining Account Type Hourly Rates Defining Project Member Hourly Rates Adding Work Types In ServiceWise, awork typeidentifies a support service tasks and the default hourly rate that the business charges for that service. Work types enable businesses to measure the cost of the support services offered to employees. Support organizations may create any number of work types in ServiceWise projects. A work type may represent a group or class of support services or specific services that area offered to employees. Project administrators may create, edit, and delete service and work types and default hourly rates in the Work Type page of the Time/Service Management folder. To add a work type: 1Click the Add button. The Work Type and Hourly Rate dialog box appears. 2Define the title of the work type in the Work Type edit box control. 3Define the default hourly rate for that work type in the Default Hourly Rate edit box. 4Click the OK button Editing Work Types Project administrators may edit work types in the Work Type page of the Time/Service Management folder. To edit a work type, select the work type in the Work Type list and click the Edit button. Update work type properties and click the OK button Deleting Work Types Project administrators may delete work types in the Work Type page of the Time/ Service Management folder. To delete a work type, select the work type in the Work Type list and click the Delete button Defining Account Type Hourly Rates In ServiceWise, businesses may track the cost of support services based on the hourly rate that the company charges for the work performed (the work type) or on the hourly rate that the company charges for the technician who performs the work. Anaccount type hourly ratedefines the default hourly rate that a business charges for professional services performed by project members belonging to a specific account type. Project administrators may edit and customize the default hourly rate for each account type and each project in the Standard Rate page. Note:Defining account type hourly rates automatically defines the project member hourly rate for all project members belonging to that account type provided that the project member hourly rates are undefined. Account type hourly rate definitions do not overwrite administrator-defined project member hourly rates. To define an account type-based hourly rate: 1Select a project member in the Account Type Hourly Rate tab of the Standard Rate page of the Time/Service Management folder. 2Click the Edit button. The Account Type Hourly Rate dialog box appears. 3Select a work type in the Work Type and Hourly Rate list control. The Work Type and Hourly Rate list control displays every administrator-defined work types available in the project. For more information see See Adding Work Types on page Click the Modify button. The Work Type and Hourly Rate dialog box appears. 5Enter a rate in the Hourly Rate edit box. 6Click the OK button. The Work Type and Hourly Rate dialog box closes Defining Project Member Hourly Rates In ServiceWise, businesses may track the cost of support services based on the hourly rate that the company charges for the work performed (the work type) or on the hourly rate that the company charges for the technician who performs the work. A project memberhourly ratedefines the default hourly rate that a business charges for professional services performed by a specific project member. Defining account type hourly rates automatically defines the project member hourly rate for all project members belonging to that account type provided that the project member hourly rates are undefined. Account type hourly rate definitions do not overwrite administrator-defined project member hourly rates. To define a project member-based hourly rate: 1Select a project member in the Member Hourly Rate tab of the Standard Rate page of the Time/Service Management folder. 2Click the Edit button. The Member Hourly Rate dialog box appears. 3Select a work type in the Work Type and Hourly Rate list control. The Work Type and Hourly Rate list control displays every administrator-defined work types available in the project. 4Click the Modify button. The Work Type and Hourly Rate dialog box appears. 5Enter a rate in the Hourly Rate edit box. 6Click the OK button. The Work Type and Hourly Rate dialog box closes Defining Project Member Hourly Rates In ServiceWise, businesses may track the cost of support services based on the hourly rate that the company charges for the work performed (the work type) or on the hourly rate that the company charges for the technician who performs the work. A project memberhourly ratedefines the default hourly rate that a business charges for professional services performed by a specific project member. Defining account type hourly rates automatically defines the project member hourly rate for all project members belonging to that account type provided that the project member hourly rates are undefined. Account type hourly rate definitions do not overwrite administrator-defined project member hourly rates. To define a project member-based hourly rate: 1Select a project member in the Member Hourly Rate tab of the Standard Rate page of the Time/Service Management folder. 2Click the Edit button. The Member Hourly Rate dialog box appears. 3Select a work type in the Work Type and Hourly Rate list control. The Work Type and Hourly Rate list control displays every administrator-defined work types available in the project. 4Click the Modify button. The Work Type and Hourly Rate dialog box appears. 5Enter a rate in the Hourly Rate edit box. 6Click the OK button. The Work Type and Hourly Rate dialog box closes. Page 121 of 145

122 Defining Standard Service Management Access Controls In ServiceWise, businesses may track the cost of support services based on the hourly rate that the company charges for the work performed (the work type) or on the hourly rate that the company charges for the technician who performs the work. A project memberhourly ratedefines the default hourly rate that a business charges for professional services performed by a specific project member. Defining account type hourly rates automatically defines the project member hourly rate for all project members belonging to that account type provided that the project member hourly rates are undefined. Account type hourly rate definitions do not overwrite administrator-defined project member hourly rates. To define a project member-based hourly rate: 1Select a project member in the Member Hourly Rate tab of the Standard Rate page of the Time/Service Management folder. 2Click the Edit button. The Member Hourly Rate dialog box appears. 3Select a work type in the Work Type and Hourly Rate list control. The Work Type and Hourly Rate list control displays every administrator-defined work types available in the project. For more information see See Adding Work Types. 4Click the Modify button. The Work Type and Hourly Rate dialog box appears. 5Enter a rate in the Hourly Rate edit box. 6Click the OK button. The Work Type and Hourly Rate dialog box closes Understanding Standard Service Management Access Controls ServiceWise uses account type-based access controls to manage workflow and implement security in work projects. All support and management tasks are protected by administrator-defined access controls. Project members may only perform time and service management tasks if they belong to an account type that has been granted the appropriate privileges in the ServiceWise project. Each account type may be granted up to six time and service management privileges in each work project. Table 20-1: Service and Time Tracking Privileges 20.4 Administering Advanced Time and Service Management Advanced Time Tracking and Service Management pages enable administrators to configure advanced time tracking and service management features. Five additional Advanced Time Tracking and Service Management pages may also be displayed in Time/Service Management folder. Work Order Budget Control Service Template Access Control Event Service Template Advanced professional service management functions require the separate purchase of the Service Agreement Manager. The Advanced Time Tracking and Service Management features require the purchase of the Service Agreement Module. Advanced time and service management administration tasks include: Understanding Standard Service Management Access Controls Defining Project Work Order Reports Enabling Incident-level Cost Controls Enabling Incident-level Sales Budgets Enabling Event-level Cost Controls Defining Project Work Order Reports Work order reports enable project members to view the time and cost of individual support incidents and to print statements and invoices for those reports. TechExcel ServiceWise features two predefined service management reports in the Crystal Reports RPT format: the Statement Report File report and the Invoice Report File report The Statement Report File report (WOStatement.rpt) The Invoice Report File report (WOInvoice.rpt) Both reports come standard in TechExcel ServiceWise. RPT is the file extension for a Crystal Reports file. Businesses may create custom RPT files using Crystal Reports and define access to those reports in the Work Order page Enabling Incident-level Cost Controls To enable incident-level cost controls, select the Support Cost Control at Incident Level check box in the Budget Control page of the Time/Service Management folder. Page 122 of 145

123 Enabling Incident-level Sales Budgets To enable incident-level sales budget controls, select the Support Budget Control at Incident Level check box in the Budget Control page of the Time/Service Management folder Enabling Event-level Cost Controls To enable event-level budget controls, select the Support Budget Control at Event Level check box in the Budget Control page of the Time/Service Management folder. While there are settings in the Service Templates that can populate some fields for budget control, most are manually set for each incident to allow you the flexibility of managing the budget for each incident. There are three properties that can be defined: Support budget control at event level if selected, you can set a limit on the amount that can be charged to a employee for each event 20.5 Administering Service Templates In ServiceWise, support organizations may use service templates to define support service time tracking, cost calculation, and billing standards. Every service template represents a support service that is offered to company employees. Service templates are only needed if the company needs to track the time spent, the cost, or the price of individual support services. Project administrators may create any number of service templates to represent the support services that are offered to employees. Every service template is either a time-related service template or a non-time-related service template: Service template administrative tasks include: Adding Service Templates Deleting Service Templates Editing Service Template Work Type Settings Defining Service Template Cost Calculation Methods Defining Service Template Sales Calculation Methods Defining Service Template Time Tracking Methods Managing Service Template Units and Unit Quantities Managing Service Template Sales Definitions Defining Maximum Support Services Per Incident or Event Defining Incident-based Service Templates Enabling and Defining Service Template Time Rounding Defining Service Template Work Codes Defining Default Work Codes with Support Plans Defining Default Work Codes without Support Plan Adding Service Templates In ServiceWise, service templates define support service time tracking, cost calculation, and billing standards. In the ServiceWise client, project members may create support services based on administrator-defined service templates. Each service template defines the work type, cost tracking method, sales tracking method, and time tracking method that is applied to a specific support service. Every service template is either a time-related service template or a non-time-related service template: Time-related service templates Non-time-related service templates To add a service template: 1Click the Add button in the Service Template page of the Time/Service Management folder. The Service Template dialog box appears. 2Enter the title of the service template in the Name edit box. 3Select a work type in the Work Type dropdown list. The Work Type dropdown list displays the administrator-defined work types that are available in the project. 4 Optional: To define the service template as a time-related service template, select the Is Time Related check box. Every service templates is either a time-related service template or a non-time-related service template: Time-related service templates Non-time-related service templates 5Click the OK button. The Service Template dialog box closes. The service template is displayed in the Service Template tree of the Service Template page Deleting Service Templates To delete a service template: 1Select a service template in the Service Template tree of the Service Template page of the Time/Service Management folder. 2Click the Delete button. A confirmation dialog box appears. 3Click the Yes button Editing Service Template Work Type Settings In ServiceWise, a work type identifies a support service task and defines the default hourly rate of that work. Every service template is defined by a work type. Two service template properties are defined when the service template is created in the project: the service template name and the work type. Project administrators may update either property in the Properties tab of the Service Template page. To edit the work type of the service template, select a work type in the Work Type dropdown list. The Work Type dropdown list displays the administrator-defined work types that are available in the project. For more information see See Adding Work Types on page Defining Service Template Cost Calculation Methods In ServiceWise, the cost of support services is determined using one of three cost calculation methods: the Based on Actual Quantity method, the Based on Predefined Quantity method, or the Fixed Cost method. Cost tracking is an optional ServiceWise feature that must be enabled in each ServiceWise project. If support service cost tracking is enabled, every service template in that project defined by a cost calculation method. To define the method for calculating costs in a service template, select an option from the Cost Method dropdown list of the Properties tab in the Service Template page. To define the method for calculating support service costs in a service template, select an option from the Cost Method dropdown list of the Properties tab in the Service Template page Defining Service Template Sales Calculation Methods In ServiceWise, the price of support services is determined using one of three price calculation methods: the Based on Actual Quantity method, the Based on Predefined Quantity method, or the Fixed Sales Amount method. Every service template is defined by a sales calculation method. Sales tracking is an optional ServiceWise feature that must be enabled in each ServiceWise project. If support service sales tracking is enabled, every service template in that project defined by a sales calculation method. To define the method for calculating sales prices in a service template, select an option from the Sales Amount Method dropdown list of the Properties tab in the Service Template page Defining Service Template Time Tracking Methods In ServiceWise, the time spent on support services is determined using one of four time tracking methods: the Edit Time Directly method, the Through Start/End Time method, the Through Time Clock method, and the Edit Time or Through Time Clock method. Time tracking is an optional ServiceWise feature that must be enabled in each ServiceWise project. If time tracking is enabled, every service template in that project defined by a time tracking method. To define the method used to track time in a service template, select an option from the Time Tracking dropdown list of the Properties tab in the Service Template page. Page 123 of 145

124 Managing Service Template Units and Unit Quantities Service templates define the standards that are used to track the time, cost, and price of support services. These services are measured and tracked in service units. A support service unit typically represents a unit of time, but it may represent any grouping that a business uses to quantify its services. Service units and unit quantity rules are defined on a template-by-template basis. In time-based service templates, a service unit always represents a period of time (minutes, hours, or days). In non-time-related service templates, a service unit may represent any counter that is useful for tracking that service. Every service template may also be defined by service unit quantity rules: a standard quantity, a maximum quantity, and a maximum billable quantity. Thestandard quantityof a service template defines the number of units represented by that service template. For example, the standard quantity of a three-day training service template would be three. Themaximum quantityof a service template defines the maximum number of units that may be expended on a support service. Themaximum billable quantityof a service template defines the maximum number of units that may be billed to an employee in a support service. To define the name of service units: Service units define the measurement that is used to quantify a support service that is offered to employees. Many different units of measurement may be used to track support services including time units, sessions, meters, or sandwiches. To define the name of non-time-related service units, enter text in the Unit Name edit box of the Properties tab. To define the name of time-related service units, select an option from the Unit Name dropdown list in the Properties tab. The Unit Name dropdown list displays three options: Hours, Hours/minutes, and Days. To define service unit standard quantities: 1Select a service template in the Service Template tree of the Service Template page in the Time/Service Management folder. 2Enter an integer in the Standard Quantity edit box of the Properties tab. To define service unit maximum quantities: 1Select a service template in the Service Template tree of the Service Template page in the Time/Service Management folder. 2Select the Limit Maximum Quantity check box in the Properties tab. 3Enter an integer in the Maximum Quantity edit box Managing Service Template Sales Definitions Service templates may be used to calculate the price of support services and bill employees for those services Defining Maximum Support Services Per Incident or Event To define maximum support service per incident or event: 1Select a service template in the Service Template tree of the Service Template page in the Time/Service Management folder. 2Enter an integer in the Maximum Copies edit box of the Properties tab Defining Incident-based Service Templates In ServiceWise, service templates may be applicable at the incident level or the event level. Service templates that are defined as applicable at the incident-level can be used to create support services that may be attached to support incidents. Service templates that are not defined as applicable to a support incidents may not be used to manage support services associated with support incidents. A service template defines rules for tracking the cost, time, and price of a support service. A support incident is a collection of data that represents a support task or set of tasks that may be managed, tracked, and processed in a ServiceWise project. Every change in ownership, work description, workflow state, and other properties is managed in workflow. To define a service template as applicable to support incidents, select the Is Applicable at Incident Level check box in the Properties tab of the Service Template page Enabling and Defining Service Template Time Rounding In ServiceWise, businesses may charge employees for support services in predefined increments of time (time intervals) and automatically round up charges to the next interval. Every service template time rounding rule is defined by a rounding interval (in minutes) and a minimum rounding trigger (in minutes or seconds). Therounding intervaldefines the time increments at which employees are billed for support services. Time increments may be defined in intervals of 0, 1, 5, 10, 15, 20, 25, 30, 45, and 60 minutes. Theminimum rounding triggerdefines the time that must pass for support services to be charged for the next time interval. Minimum rounding triggers may be defined in seconds or minutes. For example, a company that charges for services in increments of 15 minutes (the rounding interval) may define a minimum rounding trigger of 5 minutes.if a support technician worked on an incident for 1 hour 22 minutes, the employee would be charged for 1 hour 30 minutes of work. Service template time rounding is an optional ServiceWise feature that is defined on a template-by-template basis. To define service template time rounding rules: 1Select a service template in the Service Template list of the Access Control page in the Time/Service Management folder. 2Select the Support Time Rounding check box in the Properties tab. 3Click the Define Time Rounding button. The Time Rounding dialog box appears. 4Define the rounding interval: Therounding intervaldefines the time increments at which employees are billed for support services. Select an option in the Rounding dropdown list. 5Define the minimum rounding trigger: Theminimum rounding triggerdefines the time that must pass for support services to be charged for the next time interval. Minimum rounding triggers may be defined in seconds or minutes. Select an option in the Minimum Rounding dropdown list. Select a time unit in the Minimum Rounding Time Unit dropdown list. The Time Rounding dialog box closes Defining Service Template Access Controls To define service template access controls: 1Select a service template in the Service Template list of the Access Control page in the Time/Service Management folder. 2Double-click an account type in the access control list. The Access Control dialog box appears. 3To enable a privilege for the account type, select the appropriate check box. Each account type may be granted up to five service template management privileges: Is Applicable Can Own Can Submit Can Edit Can Delete 4Click the OK button. The Access Control dialog box closes Understanding Service Template Access Controls ServiceWise uses account type-based access controls to manage workflow and implement security in work projects. All service template management tasks are protected by administrator-defined access controls. Project members may only perform service template management tasks if they belong to an account type that has been granted the appropriate privileges in the ServiceWise project. Each account type may be granted up to five service template management privileges in each work project: Page 124 of 145

125 Table 20-2: Service Template Access Controls 20.6 Administering Service Template Work Codes In ServiceWise, service template work codes enable a business to define multiple rates for support services. Each work code defines the rates that a business may charge to employees (the sales price) or pay out in costs (the cost price) for a particular service. Service template work codes may be enabled and defined on a template-by-template basis. Project administrators may create three different types of work codes: Work codes that are only available with support plans Work codes that are only available without support plans Work codes that are not related to support plans Service template work code administration tasks include: Enabling Service Template Work Codes Defining Service Template Work Codes Defining Default Work Codes with Support Plans Defining Default Work Codes without Support Plan Enabling Service Template Work Codes To enable service template work codes, select the Support Work Code check box in the Work Code tab of the Service Template page. All work codes are enabled and defined on a template-by-template basis Defining Service Template Work Codes To define a service template work code: 1Select a service template. 2Enable work code support for the selected service template in the Work Code tab. 3Click the Add button. The Work Code Definition dialog box appears. 4Enter the title of the work code in the Code edit box. 5 Optional: To define the rate at which the cost of the service is calculated, enter an integer in the Cost Price edit box. 6 Optional: To define the rate at which the price of the service is calculated, enter an integer in the Sales Price edit box. 7Enter a brief note describing the work code in the Note memo field. 8Select a work code support plan option in the Support Plan dropdown list. The Support Plan dropdown list displays three options: With support plan only Without support plan only Not related to support plan 9Click the OK button. The Work Code Definition dialog box closes Defining Default Work Codes with Support Plans To define the default work code for a service template, select a work code option from the Default Work Code for Services with Support Plan dropdown list in the Work Code tab of the Service Template page. The Default Work Code for Services with Support Plan dropdown list displays every work code defined for the current service template that is available with a support plan. For more information see See Defining Service Template Work Codes on page Defining Default Work Codes without Support Plan Default work codes may be defined on a template-by-template basis. To define the default work code that is available without a support plan, select a work code option from the Default Work Code for Services without Support Plan dropdown list in the Work Code tab of the Service Template page. The Default Work Code for Services without Support Plan dropdown list displays every work code defined for the current service template that is available without a support plan. For more information see See Defining Service Template Work Codes on page Administering Service Template Volume Pricing In ServiceWise, service template volume pricing enables a business to charge different rates for support services based on the number ofunitssold. Generally, a reduced rate is offered for support services that are purchased in larger quantities. For example, a business that offers training services may charge different rates for classes based on the number of days provided one to three days of training may be billed at $1000 per day while four to ten days is billed at $850 a day. In this scenario, an employee that purchased six days of training would be billed $5100 (6 X $850) for the training. Service template volume pricing is defined on a template-by-template basis. Service template volume pricing administration tasks include: Enabling Service Template Volume Pricing Defining Service Template Volume Pricing Enabling Service Template Volume Pricing Service template volume pricing may be enabled on a template-by-template basis. To enable service template volume pricing, select the Support Volume Pricing check box in the Volume Pricing tab of the Service Template page. Page 125 of 145

126 << div> Chapter 21 Incident Notification & Escalation Administration 21 Chapter21-- Incident Notification & Escalation Administration In ServiceWise all incident notifications are based on administrator-defined incident notification rules. Project administrators may create and define any number of incident notification rules in a ServiceWise project and define triggers, conditions, actions, and subscribers for each notification rule. In this chapter: Administering Incident Notifications and Escalations Administering Incident Notifications Administering Incident Escalations Administering Incident Notification and Escalation Conditions Administering Incident Notification and Escalation Actions Administering Potential Recipients and Subscriptions Administering Notification Messages 21.1 Administering Incident Notifications and Escalations ServiceWise incident notifications and incident escalations provide support organizations the means to ensure that incident stakeholders are automatically notified at key junctures in the incident lifecycle, enforce accountability, and drive the quality of services provided to employees. All incident notifications and incident escalations are based on administrator-defined rules which identify the triggers, conditions, notification methods and messages, and recipients of every notification or escalation action. Incident notifications and escalations enable support teams to ensure that incident stakeholders are kept abreast of the status of their incidents. The primary difference between ServiceWise incident notification and incident escalation is how these rules are triggered: Incident Notification:Incident notifications alert incident stakeholders whenever key changes are made to their support incidents subscribers may be notified whenever incidents are created, updated, or closed in a support project. Incident Escalation:Incident escalations alert incident stakeholders at key points in the lifecycle of support incidents or when insufficient action is taken on an incident in a defined time period and provide for the reassignment of escalated incidents to other project members and workflow states. Both ServiceWise incident notification and incident escalation support: Customized notification triggers. The trigger defines the specificaction(incident notification) orlack of action(incident escalation) that prompts the delivery of the notification message. Customized conditions that limit the scope of the trigger to a subset of incidents based on an administrator-defined query. Customized notification messages and notification methods ( , pager, and mobile phone) Customized subscription rules including mandatory and optional notification subscriptions Push and pull notification subscriptions TechExcel ServiceWise supports bothpush notification subscriptionsandpull notification subscriptions. All incident notifications and escalations are defined by administrator-definedsubscription rules. Subscription rules determine whether a project team member must, can, or cannot receive a notification. Subscriptions rules may mandate that certain project members receive incident notifications for certain incidents while others mayopt inoropt outof individual subscriptions. Project administrators may also mandate that certain project memberneverreceive incident notifications based on incident notification rules. Push notifications are instantly and actively transferred (pushed) to subscribers. A project member is subscribed to all incidents and is always notified when changes are made to incidents based on that rule. Pull notifications are optionally sent. A project member may choose to subscribe to a notifications on an incident-by-incident basis Administering the ServiceWise Mail Service The ServiceWise Mail Service enables support organizations to integrate ServiceWise workflow, incident notification, event scheduling, and incident escalation with the convenience of . All , pager, and mobile phone notifications are sent to subscribers through the the ServiceWise Mail Service. ServiceWise incident notification and escalation and event notification and escalation require the installation and configuration of the ServiceWise Mail Service. The ServiceWise Server communicates with the ServiceWise Database Server and server to find and send messages generated within a ServiceWise project. The ServiceWise Mail Server retrieves the user name and password needed to access to the ServiceWise Database Server from the ServiceWise Application Server Reloading Settings to ServiceWise Mail Service The ServiceWise Notification Service must be stopped and restarted whenever a change is made to incident notification settings. To reload notification settings, click the Reload Service Setting button in the Incident Notifications page of the Advanced Settings folder Defining Incident Notification Activity Dates The incident notification activity date identifies the beginning date for all incident notifications in a ServiceWise project. Notification rules triggered subsequent to the activity date generate incident notifications. Notification rules triggeredpriorto the activity datedo notgenerate incident notifications. To define project incident notification activity dates, select the Start Date for Applying Notification rules control in the Incident Notifications page of the Advanced Settings folder Administering Incident Notifications In ServiceWise, incident notification is the process by which stakeholders are notified (by , pager, or mobile phone) whenever a specific change such as the creation or deletion is made to a support incident. All incident notifications are based on administrator-defined incident notification rules. An incident notification rule is defined by anotification trigger, one or morenotification actions, and one or moresubscribers. The scope of an incident notification rule may be defined by anotification condition. Using controls in the Add Notification Rule manager and the Properties tab of the Incident Notifications page, project administrators may define and update many notification rule properties. Notification Trigger:A notification trigger identifies the incident management task that triggers a notification action. Notification Condition:A notification condition limits the limit the scope of the trigger to a subset of incidents based on an administrator-defined query. Notification Action:A notification action defines the notification message and the notification method ( , pager, mobile phone). Subscribers:Subscribers represent project members that are both potential recipients of an incident notification and who are subscribed to the incident notification rule. Project administrators may assign one of four subscriptions to project members, account types, and groups: the Must Subscribe subscription, the Optional Yes subscription, the Optional No subscriptions, and the Never Subscribe subscription Enabling Incident Notification in a ServiceWise Project Incident notification is an optional ServiceWise feature that must be enabled on a project-by-project basis. To enable incident notification select the Enable Notification check box in the Incident Notifications page of the Advanced Settings folder Defining Incident Notification Rules An incident notification rule identifies which project team members are notified whenever a specific change is made to a support incident. An incident notification rule is defined by anotification trigger, one or more notification actions, andnotification subscription rules. Optional incident notification conditions limit the scope of the rule to a subset of support incidents Any number of notification rules may be defined in a project. To define an incident notification rule: Page 126 of 145

127 1Select Advanced Features > Incident Notifications. 2Click the New button. The Add Notification Rule dialog box appears. 3Provide a name and description for the incident notification rule. A unique name and note that describe the logic of the incident notification rule enables project administrators to save time when they review or update incident notifications Notification trigger 4Select a trigger in the Trigger dropdown list. The Trigger dropdown list displays six system triggers and all administrator-defined status change and field change triggers. Every incident notification rule is defined by a single notification trigger. Notification conditions 5 Optional: To limit the scope of a notification rule, select an incident notification condition in the Condition dropdown list. The Condition dropdown list displays all administrator-defined conditions. Custom notification conditions may be defined in the Notification & Escalation Conditions window. For step-by-step instructions see Administering Incident Notification and Escalation Conditions on page Click the OK button. The Add Notification dialog box closes and the incident notification rule is displayed in the Notification Rules list. Notification actions 7Define one or more notification actions in the Actions tab. A notification action is defined by anotification method( , pager, or mobile phone) and anotification message. To define an notification action, select the Notify By Sending option and select appropriate internal (team member) and external (employee) messages. To define a pager notification action, select the Notify By Pager option and select an appropriate message. To define a mobile phone notification action, select the Notify By Mobile Phone option and select an appropriate message. Custom notification messages may be defined in the Define window. Potential recipients 8Define potential recipients in the Potential Recipient tab. A potential recipient is a project team member whomay subscribeto an incident notification rule. A project team member may be identified as a potential recipient based on their account type, team group, or user variable. Potential recipient subscription rules 9Define subscription rules in the Subscription Option tab. Potential recipient subscription rules define whether a potential recipient can, cannot, or must subscribe to an incident notification. Subscription rules may be defined for each account type, team group, or user account and affect only those project team members that have been designated as potential recipients of incident notifications. Subscribers 10Define subscriptions in the Potential Recipient tab. Incident notification subscriptions define which project team members are subscribed and which project team members are not subscribed to each incident notification rule.incident notification rules are specifically defined for each user account and override all potential recipient subscription rules. To rename an incident notification rule To rename an incident notification rule, select the rule in the Notification Rules list and click the Rename button. The name of the rule may be changed in the dialog box. To delete an incident notification rule: To delete an incident notification rule, select the rule in the Notification Rules list and click the Delete button Administering Incident Notification Triggers In ServiceWise, an incident notification trigger is anaction such as the creation, edit, or deletion of an incident that prompts the ServiceWise Mail Service to deliver a notification message to a list of incident stakeholders. An incident notification is sent every time that the triggering action is performed. If the action is not performed, the incident notification rule is not triggered and the notification message is not sent. ServiceWise supports bothsystem triggersandcustom triggers System triggers ServiceWise system triggers prompt the ServiceWise Mail Service to send notification messages whenever an incident management task is performed on incidents meeting the conditions of the incident notification rule. ServiceWise supports six system triggers: On Submit:The On Submit trigger generates an incident notification whenever a new support incident is created in a project. On Forward:The On Forward trigger generates an incident notification whenever a support incident is forwarded to another project member or workflow state. On Close:The On Close trigger generates an incident notification whenever a support incident is closed in a project. On Reopen:The On Reopen trigger generates an incident notification whenever a support incident is reopened in a project. On New Note:The New Note trigger generates an incident notification whenever a note is added to a support incident. On Status Change:The On Status Change trigger generates an incident notification whenever the workflow state of an incident is changed. On Owner Change:The On Owner Change trigger generates an incident notification whenever the owner of an incident is changed. On Employee Request:The On Employee Request trigger generates an incident notification whenever a employee requests that an incident be reopened. On Support Response:The On Support Response trigger generates an incident notification whenever a project team member responds to a employee request Administering Incident Escalations Incident escalations alert incident stakeholders at key points in the lifecycle of support incidents or when insufficient action is taken on an incident in a defined time period and provide for the reassignment of escalated incidents to other project members and workflow states. Incident escalation enables project teams to ensure that ServiceWise incidents do not fall through the cracks. Project teams may be notified by , pager, or mobile phone based on an administrator-defined escalation schedule. If still no action is taken, incidents may be automatically reassigned to another project member, group, or group folder. An incident escalation rule is defined by anescalation trigger, one or more optionalescalation conditions, one or moreescalation actions, and itssubscribers the project team members that may be notified when an incident is escalated based on the rule Escalation triggers Unlike incident notifications (which are based on the changes that project members make to ServiceWise incidents), incident escalation rules are based on changes that are not made to incidents. Every incident escalation rule is defined by one of nine, system-definedescalation triggers: No Acknowledge, Open Too Long, No Progress, No Status Change Only, No Owner Change Only, Before Start Date, After Start Date, Before Finish Date, and After Finish Date Escalation conditions The scope of an escalation rule may be limited to support incidents that meet a set of criteria theincident escalation condition. An escalation condition is essentially a query that filters incidents by their incident property values. For example, a condition may limit the scope of an escalation rule to incidents that have a High or Urgent status Escalation actions All escalation triggers are time triggers. ServiceWise executes an escalation action when the status defined by the escalation trigger remains unchanged for the escalation wait period. Incident escalation actions define the time period that must pass before notifications are sent, the method used to notify subscribers ( , pager, or mobile phone), the message delivered by the notification, and the number of times that notification are sent before an escalated incident is reassigned to another project team member Subscribers ServiceWise enables administrators to manage both push and pull for each incident escalation rule using subscription rules. Project administrators may mandate that certain project members receive incident escalation notifications for certain incidents while others may opt in or opt out of individual subscriptions. Project administrators may also mandate that certain project member never receive incident escalation notifications based on incident escalation rules. Page 127 of 145

128 Administering Incident Escalation Rules Incident escalations alert incident stakeholders at key points in the lifecycle of support incidents or when insufficient action is taken on an incident in a defined time period and provide for the reassignment of escalated incidents to other project members and workflow states. An incident escalation rule is defined by anescalation trigger, one or more notification actions, andescalation subscription rules. Optional incidentescalation conditionslimit the scope of the rule to a subset of support incidents. Any number of notification rules may be defined in a project. To create incident escalation rules: 1Select Advanced Features > Incident Escalations. 2Click the New button. The Add Escalation Rule dialog box appears. 3Provide a name and description for the incident escalation rule. A unique name and note that describe the logic of the incident notification rule enables project administrators to save time when they review or update incident notifications. Escalation triggers 4Select an option from the Trigger dropdown list. The Trigger dropdown list displays four system-defined triggers: Open Too Long, No Progress, On Start Date, and On Finish Date. Escalation conditions 5 Optional: To limit the scope of an escalation rule, select an incident escalation condition in the Condition dropdown list. The Condition dropdown list displays all administrator-defined conditions. Custom escalation conditions may be defined in the Notification & Escalation Conditions window. 6Click the OK button. The Add Escalation dialog box closes and the incident escalation rule is displayed in the Escalation Rules list. Escalation actions An escalation action is defined by anescalation schedule, anescalation method( , pager, or mobile phone) and anescalation message. 7Define the escalation schedule. Anescalation scheduleis defined by anescalation wait period, arepeat schedule, and arepeat number. To define the escalation wait period, enter the number of hours and minutes in the Start Escalation controls. To define the repeat schedule, enter the number of hours and minutes in the Repeat Escalation controls. To define the repeat number, enter a digit in the Repeat Number text box. 8Select an appropriate notification message for each notification method: To define an notification action, select the Notify By Sending option and select appropriate internal and external messages. To define a pager notification action, select the Notify By Pager option and select an appropriate message. To define a mobile phone notification action, select the Notify By Mobile Phone option and select an appropriate message. Distinct messages may be identified for the last notification sent by each method. Custom notification messages may be defined in the Define window. Incident reassignment actions 9 Optional: To enable support incidents to be automatically forwarded to a different workflow state or owner if no action is taken on that incident, define incident reassignment rules. Incident reassignment actions may be defined in the Escalation Action window. Potential recipients 10Define potential recipients in the Potential Recipient tab. A potential recipient is a project team member whomay subscribeto an incident notification rule. A project team member may be identified as a potential recipient based on their account type, team group, or user variable. Potential recipient subscription rules 11Define subscription rules in the Subscription Option tab. Potential recipient subscription rules define whether a potential recipient can, cannot, or must subscribe to an incident notification. Subscription rules may be defined for each account type, team group, or user account and affect only those project team members that have been designated as potential recipients of incident notifications. Subscribers 12Define subscriptions in the Potential Recipient tab. Incident notification subscriptions define which project team members are subscribed and which project team members are not subscribed to each incident notification rule.incident notification rules are specifically defined for each user account and override all potential recipient subscription rules. Project administrators may use controls in the Escalations page to rename, incident escalation rules Understanding Incident Escalation Triggers In ServiceWise, all incident escalation triggers are time triggers which prompt the ServiceWise Mail Service to send notification messages to incident stakeholders at key points in the incident lifecycle for example, its start and finish dates or when insufficient progress is made on a support incident. Anescalation triggeridentifies theunperformedtask that triggers an administrator-defined action (incident notification or incident re-assignment). Unlike incident notification triggers which represents specific acts performed on an incident, incident escalation triggers represents acts thatare notperformed on an incident. ServiceWise supports four incident escalation triggers:. Open Too Long:The Open Too Long escalation trigger prompts escalation actions when an incident remains open beyond the period defined in the escalation schedule. No Progress:The No Progress escalation trigger prompts escalation actions when there is no change in ownership or status beyond the period defined in the escalation schedule. On Start Date:The On Start Date trigger prompts escalation actions when work on an incident has not started within the period defined in the escalation schedule. On Finish Date:The On Finish Date trigger prompts escalation actions when work on an incident has not ended within the period defined in the escalation schedule. In ServiceWise, every escalation rule is defined by a single trigger. The scope of the escalation rule may be limited by one or more escalation conditions which limit the number of support incidents that are subject to it Administering Incident Escalation Actions Incident escalation actions define the time period that must pass before notifications are sent, the method used to notify subscribers ( , pager, or mobile phone), the message delivered by the notification, and the number of times that notification are sent before an escalated incident is reassigned to another project team member. An escalation action is defined by anescalation schedule, anotification methodand, optionally, anincident reassignment action Escalation schedules All escalation triggers are time triggers. ServiceWise executes an escalation action when the state defined by the escalation trigger remains unchanged for the period defined in theescalation schedule. An escalation schedule defines the time that must pass before notifications are delivered to escalation subscribers, the number of times that notifications are sent, and the time between notifications Notification methods A notification method defines the method by which subscribers are notified that an incident has been escalated. ServiceWise supports three incident escalation notification methods: Notification: notification actions notify subscribers by whenever an incident notification rule is triggered. Page Notification:Pager notification actions notify subscribers by pager whenever an incident notification rule is triggered. Mobile Phone Notification:Mobile phone notification actions notify subscribers by mobile phone whenever an incident notification rule is triggered. A different message may be sent for every notification method Incident reassignment actions An incident reassignment action defines rules for routing escalated support incidents to specific workflow states or project team members at the end of the incident escalation schedule. Incident reassignment actions are an optional feature that must be enabled and defined in each incident escalation rule Administering Incident Escalation Schedules An escalation schedule defines the time that must pass before notifications are delivered to escalation subscribers, the number of times that notifications may be sent, and the Page 128 of 145

129 time between each notification. All escalation triggers are time triggers. ServiceWise executes an escalation action when the state defined by the escalation trigger remains unchanged for the escalation wait period. Using controls in the Escalation Action window, project administrators may define an escalation wait period, an escalation schedule, and a repeat number for each incident escalation rule. Figure 21-1: Schedule Area of the Add Escalation Action Dialog Box Anescalation scheduleis defined by anescalation wait period, arepeat schedule, and arepeat number. The escalation wait period defines the time that must pass before the subscribers are notified of the incident escalation. The escalation wait period is defined in hours and minutes. The escalation repeat schedule defines time between escalation actions. The escalation repeat period is defined in hours and minutes. The repeat number defines the number of times that incidents may be escalated before the incident is reassigned or the incident expires. After the final escalation action is performed, escalated incidents may be automatically reassigned to another project member, group, or group folder based on administratordefined reassignment settings. To define an escalation schedule: 1Define an incident escalation rule, escalation trigger and trigger conditions in the Incident Escalations page. 2Click the Add button in the Action tab. Escalation actions may be defined whenever you create or edit an incident escalation rule. The Escalation Action window appears. 3Define the escalation wait period in the Start Escalation if Incident Remain Open After text box. The escalation wait period defines the time that must pass before the subscribers are notified of the incident escalation. The escalation wait period is defined in hours and minutes. 4Define the escalation repeat schedule in the Repeat Escalation Every text box. The escalation repeat schedule defines time between escalation actions. The escalation repeat period is defined in hours and minutes. 5Define the repeat number in the Repeat Number text box. The repeat number defines the number of times that incidents may be escalated before the incident is reassigned or the incident expires Administering Incident Reassignment Actions An incident reassignment action defines rules for routing escalated support incidents to specific workflow states or project team members at the end of the incident escalation schedule. If incident reassignment is enabled, the escalated incident is reassigned and its workflow state is changedonly afterevery scheduled escalation action is performed. Using controls in the Escalation Action window, project members may enable incident reassignment and routing rules, designate a project team member or group folder as the incident owner, and define workflow state changes for each incident escalation rule. Figure 21-2: Edit Escalation Action Window (Detail) The target incident owner of an incident reassignment action may be identified by user account, group folder, or the{submitter} user variable. To enable incident reassignment: 1Define incident escalation actions in the Actions tab of the Incident Escalation page. Incident reassignment actions may be defined whenever you create or edit incident escalation actions in the Actions tab of the Incident Escalation page. 2Select the Do Re-assignment After the Actions Above check box. Incident reassignment actions must be specifically enabled for each incident escalation rule. 3Select an option in the Re-assign To dropdown list. The Re-assign To dropdown list displays all user accounts, account types, team group and group folders as well as multiple user variables: {Submitter} {Auto Assigned} {Current Owner} {Primary Support Engineer} Salesperson} 4 Optional: To apply routing rules, click the Apply Auto Routing Rules check box. 5Select an incident workflow state in the Change Progress Status dropdown list. The Change Progress Status dropdown list displays all administrator-defined workflow states as well as the{no Change} state variable Administering Incident Notification and Escalation Conditions In ServiceWise, a condition is a query that defines the scope of an incident notification or incident escalation rule. Support incidents that do not met the condition criteria are not subject to the notification or escalation rule and no action is taken when that incident triggers an escalation or notification action. A condition query is a set of instructions for identifying a subset of support incidents that are subject to an incident notification or escalation rule. Every condition query consists of one or more search conditions, which identify the data fields searched and the field value criteria for each field. Multiple search conditions may be organized into search terms and filtered by using theand, NOT, and OR operators. Using controls in the Incident Notification & Escalation Condition window, project administrators may define and manage incident conditions. Page 129 of 145

130 Figure 21-3: Incident Notification & Escalation Condition Window Condition queries may be based on incident properties tracked in system fields, custom fields, and seven system-defined variables Administering Incident Notification and Escalation Actions In ServiceWise, an incident notification or incident escalation action defines the notification messages sent to rule subscribers and notification methods used to deliver those messages. A notification action is defined by anotification method( , pager, or mobile phone) and anotification message. An escalation action is defined by anescalation schedule, anescalation method( , pager, or mobile phone) and anescalation message Notification methods ServiceWise supports three notification methods for both incident notifications and incident escalations: Notification: notification actions notify subscribers by whenever an incident notification rule is triggered. Page Notification:Pager notification actions notify subscribers by pager whenever an incident notification rule is triggered. Mobile Phone Notification:Mobile phone notification actions notify subscribers by mobile phone whenever an incident notification rule is triggered. If an administrator enables all four notification actions for a incident notification rule, every subscriber to that incident notification will receive notification by , pager,andmobile phone when that notification rule is triggered Defining Notification Action Addresses ServiceWise enables project administrators to define incident notification rules that automatically notify many different subscribers of the status of ServiceWise incidents. Incident notification may be sent to project members, employee contacts, and administrator-defined address lists. The addresses of incident notification subscribers are managed in different tools in ServiceWise applications. Project member addresses, pager addresses, and mobile phone addresses are all managed in the User Manager. Project member addresses must be defined in the User Manager for project members to receive incident notifications. All ServiceWise project members addresses are managed at the system level. Project administrators may create a unique list of addresses for each notification rule. The addresses on that list are notified automatically whenever the incident notification rule is triggered Defining Notification Actions To define notification actions: 1Select an notification rule in the Notification Rule list of the Incident Notifications page. 2Select the Actions tab. 3Select the By Sending check box. Project administrators must enable notification. 4Select an option from the Format dropdown list. Project administrators may select the format used to send notifications to (internal) project members. The Format dropdown list displays all of the formats defined in the Format manager. Project administrators may define new formats by clicking the Setup button. 5Select an option from the Format for Employee dropdown list. Project administrators may select the format used to send notifications to (external) employees. The Format for Employee dropdown list displays all of the formats defined in the Format manager. Project administrators may define new formats by clicking the Setup button Defining Pager and Mobile Phone Notifications Pager and mobile phone notifications are automatically sent to the number recorded for that project team member in the system. All pager and mobile phone numbers are defined at the site-level in the System Settings project. To define a pager or mobile phone notification: 1Define an incident escalation rule, escalation trigger and trigger conditions. 2Click the Add button in the Action tab. Escalation actions may be defined whenever you create or edit an incident escalation rule. The Escalation Action window appears. 3Click the Pager & Mobile Phone Notification button. The Pager & Mobile Phone Notification window appears. 4 Optional: To define an incident escalation pager action, select the Enable Pager Notification check box and select an message in the Pager dropdown list. 5 Optional: To define an incident escalation mobile phone action, select the Enable Pager Notification check box and select an message in the Mobile Phone dropdown list. The option selected in the Format identifies the message that is sent to rule subscribers when an incident is first escalated and for every subsequent notification prior to the final notification Defining Incident Notifications notification actions send notifications to project members and employees whenever an event notification rule is triggered. notifications may also be sent to an administrator-defined list of addresses and user-defined cc lists. The administrator may define a list of addresses that receive all notifications relevant to a specific incident notification rule. Individual project members may define a cc list of addresses for incidents that they subscribe to in the ServiceWise client. Project administrators must enable incident specific cc lists for each incident notification rule. Using controls in the Escalation Action window, project administrators may define the messages to be sent to rule subscribers whenever the incident escalation rule is triggered. Figure 21-4: Escalation Action Window (Detail) To define an incident escalation notification: 1Define an incident escalation rule, escalation trigger and trigger conditions. 2Click the Add button in the Action tab. Escalation actions may be defined whenever you create or edit an incident escalation rule. The Escalation Action window appears. 3Select an message in the Format dropdown list. 4Select an message in the Last Format dropdown list. The Format and Last Format dropdown lists display all administrator-defined messages. The option selected in the Format identifies the message that is sent to rule subscribers when an incident is first escalated and for every subsequent notification prior to the final notification. The option selected in the Last Format identifies the last message that is sent to rule subscribers before the escalated incident is reassigned Administering Potential Recipients and Subscriptions For each incident notification rule, recipients are defined at three levels: (1)potential recipientsare identified by account type, team group, or user variable; (2) subscription rulesare Page 130 of 145

131 defined for each account type and team group these rules determine whether project members may, may not, or must receive incident notifications; (3)subscriptions are defined on an account-by-account basis. Potential Recipient:A potential recipient is a project team member whomay subscribeto an incident notification rule. To be notified by a notification action, the project member must be subscribed to an incident notification rule. Subscription Rule:Subscription rules enable the project administrator to define whether a potential recipient can, cannot, or must subscribe to an incident notification based on his or her account type or team group Identifying Potential Recipients of Notification Actions A potential recipient is a project team member whomay subscribeto an event notification rule. A project team member may be identified as a potential recipient based on their account type, team group, or potential recipient variable. A project team member may be designated as a potential recipient based on his or her account type, team group, orrelationship with an event.in ServiceWise, these relationships are represented bypotential recipient variables. Most potential recipients are identified by account type or team group membership Potential recipient variables A potential recipient variable is a dynamic placeholder that represents an incident stakeholder a project member or employee that has worked on an incident. For example, a user may be designated as potential recipients based on having submitted or previiously owned the support incident or event. {Incident Owner}:The {Incident Owner} potential recipient variable enables administrators to notify the owner of the incident by notification actions. {Incident Submitter}:The {Incident Submitter} potential recipient variable enables administrators to notify the submitter of the incident by notification actions. {Last Previous Owner}:The {Last Previous Owner} potential recipient variable enables administrators to notify previous owner of the incident by notification actions. {All Previous Owners}:The {All Previous Owners} potential recipient variable enables administrators to notify all previous owners of the incident by notification actions. {User Defined Address}:The {User Defined Address} potential recipient variable enables administrators to define a list of addresses. notifications are sent to all addresses on that list. {Linked Incident Owner}:The {Linked Incient Owner} potential recipient variable enables administrators to notify the owners of any events that are linked to the incident by notification actions.. {Linked Incident Submitter}:The {Linked Incient Submitter} potential recipient variable enables administrators to notify the submitters of any incidents linked to the incident by notification actions. {Incident Contacts}:The {Incident Contacts} potential recipient variable enables administrators to notify the contacts assigned to the incident by notification actions. {Sales person}:the {Sales person} potential recipient variable enables administrators to notify the salespersons assigned to incident by notification actions. The scope of most potential recipient variables may be further limited by account type.. Once defined, only project team members that belong to a specifc account type may be designated as potential recipients based on their relationship to the incident or event Defining the Scope of Potential Recipient Variables In ServiceWise, a potential recipient variable represents a project team member that may be designated as apotential recipientof an incident notification action based on their relationship with a support incident. Using one or more user variables, a project administrator may ensure that every stakeholder kept up-to-date with their incidents. The scope of user variables may be limited by account type or project: The scope of most user variables may be limited byaccount type. Only those project members that belong to the selected account types are defined as potential recipients of notification actions. The scope of the{linked Incident Submitter} and {Linked Incident Owner} user variables may be defined by project. Only those project members that submitted or currently own a linked incident in the selected projects are defined as potential recipients of notification actions. To define the scope of a user variable by account type: 1Select an incident notification rule. 2Double-click a user variable in the Potential Recipient tab. The Notification/Escalation window appears. 3Select one or more account types in the Account Types list. The Account Types list displays the name of every administrator-defined account type. 4Click the OK button. To define the scope of a user variable by project: 1Select an incident notification rule. 2Double-click a user variable in the Potential Recipient tab. The Notification/Escalation window appears. 3Select one or more account types in the Account Types list. The Account Types list displays the name of every project in the ServiceWise site. In an integrated ServiceWise site ServiceWise support incidents may be linked to support incidents in other projects and to DevSpec requirements or specifications. 4Click the OK button Defining User-Defined Address List The{User Defined Address} user variable represents an administrator-defined list of addresses that may designated as potential recipients of notification actions. notifications are sent to every address on that list when the incident notification rule is triggered. Project administrators may add any number of addresses to the User Define Addresses list. Each address must be separated by a semicolon (;). To define a list of addresses: Chapter 22 Event Notification & Escalation Administration 22 Chapter22 -- Event Notification & Escalation Administration In ServiceWise all event notifications are based on administrator-defined event notification rules. Project administrators may create and define any number of event notification rules in a ServiceWise project and define triggers, conditions, actions, and subscribers for each notification rule. In this chapter: Administering Event Notifications and Escalations Administering Event Notifications Administering Event Escalations Administering Event Notification and Escalation Conditions Administering Event Notification and Escalation Actions Administering Potential Recipients and Subscriptions Select the Yes or No option in the Option dropdown list Administering Event Notifications and Escalations ServiceWise event notifications and event escalations provide support organizations the means to ensure that event stakeholders are automatically notified at key junctures in the event lifecycle, enforce accountability, and drive the quality of the services offered to company employees. All event notifications and event escalations are based on administrator-defined rules which identify the triggers, conditions, notification methods and messages, and recipients of every notification or escalation action. Event notifications and escalations enable support teams to ensure that event stakeholders are kept abreast of the status of their events. The primary difference between ServiceWise event notification and event escalation is how these rules are triggered: Event Notification:Event notifications alert event stakeholders whenever key changes are made to their support events subscribers may be notified whenever events are Page 131 of 145

132 created, updated, or closed in a support project. Event Escalation: Event escalations alert event stakeholders at key points in the lifecycle of support events or when insufficient action is taken on an event in a defined time period and provide for the reassignment of escalated events to other project members and workflow states. Both ServiceWise event notification and event escalation support: Customized notification triggers. The trigger defines the specificaction(event notification) orlack of action(event escalation) that prompts the delivery of the notification message. Customized conditions that limit the scope of the trigger to a subset of events based on an administrator-defined query. Customized notification messages and notification methods ( , pager, and mobile phone) Customized subscription rules including mandatory and optional notification subscriptions Push and pull notification subscriptions TechExcel ServiceWise supports bothpush notification subscriptionsandpull notification subscriptions. All event notifications and escalations are defined by administrator-definedsubscription rules. Subscription rules determine whether a project team member must, can, or cannot receive a notification. Subscriptions rules may mandate that certain project members receive event notifications for certain events while others mayopt inoropt outof individual subscriptions. Project administrators may also mandate that certain project memberneverreceive event notifications based on event notification rules. Push notifications are instantly and actively transferred (pushed) to subscribers. A project member is subscribed to all events and is always notified when changes are made to events based on that rule. Pull notifications are optionally sent. A project member may choose to subscribe to a notifications on an event-by-event basis Administering Event Notifications In ServiceWise, event notification is the process by which stakeholders are notified (by , pager, or mobile phone) whenever a specific change such as the creation or deletion is made to a support event. All event notifications are based on administrator-defined event notification rules. An event notification rule is defined by anotification trigger, one or morenotification actions, and one or moresubscribers. The scope of an event notification rule may be defined by anotification condition. Using controls in the Add Notification Rule manager and the Properties tab of the Event Notifications page, project administrators may define and update many notification rule properties. Notification Trigger: A notification trigger identifies the event management task that triggers a notification action. Notification Condition:A notification condition limits the limit the scope of the trigger to a subset of events based on an administrator-defined query. Notification Action:A notification action defines the notification message and the notification method ( , pager, mobile phone). Subscribers: Subscribers represent project members that are both potential recipients of an event notification and who are subscribed to the event notification rule. Project administrators may assign one of four subscriptions to project members, account types, and groups: the Must Subscribe subscription, the Optional Yes subscription, the Optional No subscriptions, and the Never Subscribe subscription Enabling Event Notification in a ServiceWise Project Event notification is an optional ServiceWise feature that must be enabled on a project-by-project basis. To enable event notification select the Enable Notification check box in the Event Notifications page of the Advanced Settings folder Defining Event Notification Rules An event notification rule identifies which project team members are notified whenever a specific change is made to a support event. An event notification rule is defined by anotification trigger, one or more notification actions, andnotification subscription rules. Optional event notification conditions limit the scope of the rule to a subset of support events Any number of notification rules may be defined in a project. To define an event notification rule: 1Select Advanced Features > Event Notifications. 2Click the New button. The Add Notification Rule dialog box appears. 3Provide a name and description for the event notification rule. A unique name and note that describe the logic of the event notification rule enables project administrators to save time when they review or update event notifications. Notification trigger 4Select a trigger in the Trigger dropdown list. The Trigger dropdown list displays six system triggers and all administrator-defined status change and field change triggers. Every event notification rule is defined by a single notification trigger. Notification conditions 5 Optional: To limit the scope of a notification rule, select an event notification condition in the Condition dropdown list. The Condition dropdown list displays all administrator-defined conditions. Applicable event templates 6Select one or more event templates in the Applicable Regular or Co-Owner Event Template list. The scope of the event notification rule is restricted to support events based on the selected regular and co-owner event templates. 7Click the OK button. The Add Notification dialog box closes and the event notification rule is displayed in the Notification Rules list. Notification actions 8Define one or more notification actions in the Actions tab. A notification action is defined by anotification method( , pager, or mobile phone) and anotification message. To define an notification action, select the Notify By Sending option and select appropriateinternal(project team member) andexternal(employee) messages. To define a pager notification action, select the Notify By Pager option and select an appropriate message. To define a mobile phone notification action, select the Notify By Mobile Phone option and select an appropriate message. Custom notification messages may be defined in the Define window. For step-by-step instructions see Select the Yes or No option in the Option dropdown list.. Potential recipients 9Define potential recipients in the Potential Recipient tab. A potential recipient is a project team member whomay subscribeto an event notification rule. A project team member may be identified as a potential recipient based on their account type, team group, or potential recipient variable. Potential recipient subscription rules 10Define subscription rules in the Subscription Option tab. Potential recipient subscription rules define whether a potential recipient can, cannot, or must subscribe to an event notification. Subscription rules may be defined for each account type, team group, or user account and affect only those project team members that have been designated as potential recipients of event notifications. Subscribers 11Define subscriptions in the Potential Recipient tab. Event notification subscriptions define which project team members are subscribed and which project team members are not subscribed to each event notification rule.event notification rules are specifically defined for each user account and override all potential recipient subscription rules. To rename an event notification rule To rename an event notification rule, select the rule in the Notification Rules list and click the Rename button. The name of the rule may be changed in the dialog box. To delete an event notification rule: To delete an event notification rule, select the rule in the Notification Rules list and click the Delete button Administering Event Notification Triggers In ServiceWise, an event notification trigger is anaction such as the creation, edit, or deletion of an event that prompts the ServiceWise Mail Service to deliver a notification message to a list of event stakeholders. An event notification is sent every time that the triggering action is performed. If the action is not performed, the event notification rule is not triggered and the notification message Page 132 of 145

133 is not sent. ServiceWise supports bothsystem triggersandcustom triggers. System triggers ServiceWise system triggers prompt the ServiceWise Mail Service to send notification messages whenever an event management task is performed on events meeting the conditions of the event notification rule. ServiceWise supports six system triggers: New:The New Event trigger generates an event notification whenever a new support event is created in a project. Close: The Closed Event trigger generates an event notification whenever a support event is closed in a project. Status Change:Status change triggers generate event notifications based on changes to the workflow state of support events. Owner Change: Owner change triggers generate event notifications based on changes in event ownership Administering Event Escalations Event escalations alert event stakeholders at key points in the lifecycle of support events or when insufficient action is taken on an event in a defined time period and provide for the reassignment of escalated events to other project members and workflow states. Event escalation enables project teams to ensure that ServiceWise events do not fall through the cracks. Project teams may be notified by , pager, or mobile phone based on an administrator-defined escalation schedule. If still no action is taken, events may be automatically reassigned to another project member, group, or group folder. An event escalation rule is defined by anescalation trigger, one or more optionalescalation conditions, one or moreescalation actions, and itssubscribers the project team members that may be notified when an event is escalated based on the rule. Escalation triggers Unlike event notifications (which are based on the changes that project members make to ServiceWise events), event escalation rules are based on changes that are not made to events. Every event escalation rule is defined by one of four, system-definedescalation triggers: On New Event, On Close Event, On Status Change, and On Owner Change. Escalation conditions The scope of an escalation rule may be limited to support events that meet a set of criteria theevent escalation condition. An escalation condition is essentially a query that filters events by their event property values. For example, a condition may limit the scope of an escalation rule to events that have a High or Urgent status. Escalation actions All escalation triggers are time triggers. ServiceWise executes an escalation action when the status defined by the escalation trigger remains unchanged for the escalation wait period. Event escalation actions define the time period that must pass before notifications are sent, the method used to notify subscribers ( , pager, or mobile phone), the message delivered by the notification, and the number of times that notification are sent before an escalated event is reassigned to another project team member. Subscribers ServiceWise enables administrators to manage both push and pull for each event escalation rule using subscription rules. Project administrators may mandate that certain project members receive event escalation notifications for certain events while others may opt in or opt out of individual subscriptions. Project administrators may also mandate that certain project member never receive event escalation notifications based on event escalation rules Administering Event Escalation Rules Event escalations alert event stakeholders at key points in the lifecycle of support events or when insufficient action is taken on an event in a defined time period and provide for the reassignment of escalated events to other project members and workflow states. An event escalation rule is defined by anescalation trigger, one or more notification actions, andescalation subscription rules. Optional eventescalation conditionslimit the scope of the rule to a subset of support events. Any number of notification rules may be defined in a project. To create event escalation rules: 1Select Advanced Features > Event Escalations. 2Click the New button. The Add Escalation Rule dialog box appears. 3Provide a name and description for the event escalation rule. A unique name and note that describe the logic of the event notification rule enables project administrators to save time when they review or update event notifications. Escalation triggers 4Select an option from the Trigger dropdown list. The Trigger dropdown list displays four system-defined triggers: the On New Event, On Close Event, On Status Change, and the On Owner Change triggers. For more information see Understanding Event Escalation Triggers. Escalation conditions 5 Optional: To limit the scope of an escalation rule, select an event escalation condition in the Condition dropdown list. The Condition dropdown list displays all administrator-defined conditions. Custom escalation conditions may be defined in the Notification & Escalation Conditions window. For step-by-step instructions see Administering Event Notification and Escalation Conditions. Applicable event templates 6Select one or more event templates in the Applicable Regular or Co-Owner Event Template list. The scope of the event escalation rule is restricted to support events based on the selected regular and co-owner event templates. 7Click the OK button. The Add Escalation dialog box closes and the event escalation rule is displayed in the Escalation Rules list. Escalation actions An escalation action is defined by anescalation schedule, anescalation method( , pager, or mobile phone) and anescalation message. 8Define the escalation schedule. Anescalation scheduleis defined by anescalation wait period, arepeat schedule, and arepeat number. To define the escalation wait period, enter the number of hours and minutes in the Start Escalation controls. To define the repeat schedule, enter the number of hours and minutes in the Repeat Escalation controls. To define the repeat number, enter a digit in the Repeat Number text box. 9Select an appropriate notification message for each notification method: To define an notification action, select the Notify By Sending option and select appropriate internal and external messages. To define a pager notification action, select the Notify By Pager option and select an appropriate message. To define a mobile phone notification action, select the Notify By Mobile Phone option and select an appropriate message. Custom notification messages may be defined in the Define window. For step-by-step instructions see Select the Yes or No option in the Option dropdown list.. Event reassignment actions 10 Optional: To enable support events to be automatically forwarded to a different workflow state or owner if no action is taken on that event, define event reassignment rules. Event reassignment actions may be defined in the Escalation Action window. For step-by-step instructions see Administering Event Escalation Reassignment Actions on page 436. Potential recipients 11Define potential recipients in the Potential Recipient tab. A potential recipient is a project team member whomay subscribeto an event notification rule. A project team member may be identified as a potential recipient based on their account type, team group, or potential recipient variable. Potential recipient subscription rules 12Define subscription rules in the Subscription Option tab. Potential recipient subscription rules define whether a potential recipient can, cannot, or must subscribe to an event notification. Subscription rules may be defined for each account type, team group, or user account and affect only those project team members that have been designated as potential recipients of event notifications. Subscribers 13Define subscriptions in the Potential Recipient tab. Event notification subscriptions define which project team members are subscribed and which project team members are not subscribed to each event notification Page 133 of 145

134 rule.event notification rules are specifically defined for each user account and override all potential recipient subscription rules. Project administrators may use controls in the Escalations page to rename, event escalation rules Understanding Event Escalation Triggers In ServiceWise, all event escalation triggers are time triggers which prompt the ServiceWise Mail Service to send notification messages to event stakeholders at key points in the event lifecycle for example, its start and finish dates. Anescalation triggeridentifies theunperformedtask that triggers an administrator-defined action (event notification or event re-assignment). Unlike event notification triggers which represents specific acts performed on an event, event escalation triggers represents acts thatare notperformed on an event. ServiceWise supports four event escalation triggers:. On New Event On Close Event On Owner Change On Status Change In ServiceWise, every escalation rule is defined by a single trigger. The scope of the escalation rule may be limited by one or more escalation conditions which limit the number of support events that are subject to it Administering Event Escalation Actions Event escalation actions define the time period that must pass before notifications are sent, the method used to notify subscribers ( , pager, or mobile phone), the message delivered by the notification, and the number of times that notification are sent before an escalated event is reassigned to another project team member. An escalation action is defined by anescalation schedule, anotification methodand, optionally, anevent reassignment action: Escalation schedules An escalation schedule defines the time that must pass before notifications are delivered to escalation subscribers, the number of times that notifications are sent, and the time between notifications. Notification methods A notification method defines the method by which subscribers are notified that an event has been escalated. ServiceWise supports three event escalation notification methods: Notification: notification actions notify subscribers by whenever an event notification rule is triggered. Page Notification: Pager notification actions notify subscribers by pager whenever an event notification rule is triggered. Mobile Phone Notification: Mobile phone notification actions notify subscribers by mobile phone whenever an event notification rule is triggered. A different message may be sent for every notification method. Event reassignment actions An event reassignment action defines rules for routing escalated support events to specific workflow states or project team members at the end of the event escalation schedule. Event reassignment actions are an optional feature that must be enabled and defined in each event escalation rule Administering Event Escalation Schedules An escalation schedule defines the time that must pass before notifications are delivered to escalation subscribers, the number of times that notifications may be sent, and the time between the delivery of each notification. All escalation triggers are time triggers. ServiceWise executes an escalation action when the state defined by the escalation trigger remains unchanged for the escalation wait period. Using controls in the Escalation Action window, project administrators may define an escalation wait period, an escalation schedule, and a repeat number for each event escalation rule. Anescalation scheduleis defined by anescalation wait period, arepeat schedule, and arepeat number. The escalation wait period defines the time that must pass before the subscribers are notified of the event escalation. The escalation wait period is defined in hours and minutes. The escalation repeat schedule defines time between escalation actions. The escalation repeat period is defined in hours and minutes. The repeat number defines the number of times that events may be escalated before the event is reassigned or the event expires. After the final escalation action is performed, escalated events may be automatically reassigned to another project member, group, or group folder based on administrator-defined reassignment settings. For more information see Administering Event Escalation Reassignment Actions. To define an escalation schedule: 1Define an event escalation rule, escalation trigger and trigger conditions in the Event Escalations page. 2Click the Add button in the Action tab. Escalation actions may be defined whenever you create or edit an event escalation rule. The Escalation Action window appears. 3Define the escalation wait period in the Start Escalation if Event Remain Open After text box. The escalation wait period defines the time that must pass before the subscribers are notified of the event escalation. The escalation wait period is defined in hours and minutes. 4Define the escalation repeat schedule in the Repeat Escalation Every text box. The escalation repeat schedule defines time between escalation actions. The escalation repeat period is defined in hours and minutes. 5Define the repeat number in the Repeat Number text box. The repeat number defines the number of times that events may be escalated before the event is reassigned or the event expires Administering Event Escalation Reassignment Actions An event reassignment action defines rules for routing escalated support events to specific workflow states or project team members at the end of the event escalation schedule. If event reassignment is enabled, the escalated event is reassigned and its workflow state is changedonly afterevery scheduled escalation action is performed. Using controls in the Escalation Action window, project members may enable event reassignment and routing rules, designate a project team member or group folder as the event owner, and define workflow state changes for each event escalation rule. The target event owner of an event reassignment action may be identified by user account, group folder, or the{submitter} potential recipient variable. To enable event escalation reassignment: 1Define event escalation actions in the Actions tab of the Event Escalation page. Event reassignment actions may be defined whenever you create or edit event escalation actions in the Actions tab of the Event Escalation page. 2Select the Do Event Re-assignment After the Actions Above check box. Event reassignment actions must be specifically enabled for each event escalation rule. 3Select a project team member in the Re-assign To dropdown list. The Re-assign To dropdown list displays all user accounts and group folders as well as the multiple potential recipient variables.: {Submitter} {Auto Assigned} {Current Owner} {Primary Support Engineer} {Salesperson} 22.4 Administering Event Notification and Escalation Conditions In ServiceWise, an event condition is a query that defines the scope of an event notification or event escalation rule. Escalation conditions may be based on event property values or on the property values of its parent support incident. support events that do not met the condition criteria are not subject to the notification or escalation rule and no action is taken when that event triggers an escalation or notification action. Using controls in the Event Notification & Escalation Condition window, project administrators may define and manage event conditions. Page 134 of 145

135 Figure 22-1: Event Notification & Escalation Condition Window An event condition query is a set of instructions for identifying a subset of support events that are subject to an event notification or escalation rule. Every condition query consists of one or more search conditions, which identify the data fields searched and the field value criteria for each field. Multiple search conditions may be organized into search terms and filtered by using theand, NOT, and OR operators. Escalation condition queries may be based on event property values or parent incident property values tracked in system fields, custom fields, and seven system-defined variables. Event Fields:Event conditions may be defined by event property definitions that tracked in six fields: the Event Owner, Created By, Event Status, Start Date, Due Date, Create Date system fields. Conditions may also be defined based on keywords in the event title or description. System Fields:Event conditions may be defined by incident property definitions that tracked in 13 system fields. Custom Fields: Event conditions may be defined by incident property definitions that tracked in all custom fields. System Variables: Event conditions may be defined by incident property definitions based on dynamic field or user variables. System variables include the incident ID, the incident owner, the incident submitter, and the incident subproject Administering Event Notification and Escalation Actions In ServiceWise, an event notification or event escalation action identifies thenotification methods(by , pager, or mobile phone) and thenotification messagesthat are sent by each method to the notification or escalation rule subscribers. Event notification and event escalation rules share a common repository of notification messages and use the same notification methods. However, there are important distinctions between the two based on how each is triggered. An event notification action is defined by anotification method( , pager, or mobile phone) and anotification message. Notification actions are triggered by the execution of a specified incident or event management task. An escalation action is defined by anescalation schedule, anescalation method( , pager, or mobile phone) and anescalation message. Escalation actions are triggered when a specified incident or event management task is not performed within a specified time period as identified by escalation schedule. Also, ServiceWise event notification supports notification actions that are specifically targeted toexternal subscribers. An external subscriber is a employee that has been designated as an incident stakeholder and subscribed to a notification rule. ServiceWise supports three notification methods for both event notifications and event escalations: Notification: notification actions notify subscribers by whenever an event notification or event escalation rule is triggered. Event notification actions may be targeted to both internal and external subscribers. Page Notification:Pager notification actions notify subscribers by pager whenever an event notification or event escalation rule is triggered. Mobile Phone Notification: Mobile phone notification actions notify subscribers by mobile phone whenever an event notification or event escalation rule is triggered. If an administrator enables all three notification actions for a event notification rule, every subscriber to that event notification will receive notification by , pager, and mobile phone when that notification rule is triggered Identifying Notification Action Addresses ServiceWise enables project administrators to define event notification rules that automatically notify many different subscribers of the status of ServiceWise events. Event notification may be sent to project members, employee contacts, and administrator-defined address lists. The addresses of event notification subscribers are managed in different tools in ServiceWise applications. Project member addresses, pager addresses, and mobile phone addresses are all managed in the User Manager. Project member addresses must be defined in the User Manager for project members to receive event notifications. All ServiceWise project members addresses are managed at the system level. Project administrators may create a unique list of addresses for each notification rule. The addresses on that list are notified automatically whenever the event notification rule is triggered Defining Event Notifications notification actions send notifications to project members and employees whenever an event notification rule is triggered. Chapter 23 Outlook Sync Administration 23 Chapter23-- Outlook Sync Administration 23.1 TechExcel Outlook Sync Overview TechExcel Outlook Sync provides Microsoft Outlook users the ability to interact with TechExcel ServiceWise data from directly within Outlook. The TechExcel Outlook Synd adds additional buttons to the Microsoft Outlook interface making it easy for salespeople and customer support technicians to synchronize activities performed within Outlook to ServiceWise. Synchronizing communications, activities, and tasks from Outlook to ServiceWise improves both user efficiency and visibility Feature Summary Capture Outlook s Incoming and outgoing Outlook s may be selected and linked with the appropriate customer in ServiceWise with a single click. Or, more detailed Employee search may also be used to find and match the with the appropriate customer record. Automatic Record Matching s sent and received are automatically matched with existing ServiceWise information based on matching addresses. Support teams link new and existing s with employees, requests, or support incidents while adding Outlook s to ServiceWise. If no match is found, users may also choose to perform a search of ServiceWise employee data from within Outlook. Online/Offline Customer Contact Support Search the ServiceWise employee database from within Outlook even when offline. TechExcel Outlook Sync maintains a local database of customer, contact, opportunity, and event information so sales and support users may access and update information while offline. All updates made locally will be synchronized with the ServiceWise server when online. Employee Manager Page 135 of 145

136 Add or update ServiceWise employee information directly from Outlook at the same time you add an , task, or appointment. Create Outlook Tasks and Activities from ServiceWise Events ServiceWise Events may be configured to automatically create calendar appointments or tasks in Microsoft Outlook. ServiceWise Events are also workflow driven so you may configure a process which automatically updates users task lists and calendars as a part of the IT management or support workflow to ensure incidents, requests, or changes are worked on consistently and in a timely manner Requirements Server Requirements TechExcel ServiceWise 8.0 or above Outlook Integration must be enabled and configured by Administrator End User Requirements Microsoft Windows 2000, XP, XP Professional, or Vista Microsoft Outlook XP, 2003, and 2007 Permission to perform Outlook Sync Actions 23.4 System Administration - Configuring TechExcel ServiceWise for use with Outlook Sync TechExcel System Administrators must configure Outlook Sync within the Admin Client before use. There are two areas within the Admin Client that must be configured: 1. Support Member Manager System administrators must grant team members permission to use Outlook Sync. This privilege is granted using a new checkbox in the Team Member Manager. The image below shows a new privilege Can perform Outlook Integration that must be checked for team members allowed to perform actions. 2. Outlook Integration Settings The second step is to configure the Outlook Integration settings found under the Advanced Project Settings folder in the Admin Client. The image below shows the new Outlook Integration page and is followed by a brief description of each control on the page. 1.Enable Outlook integration This checkbox must be checked to enable syncing Outlook items with events and saving s as events in the work project. Page 136 of 145

137 Event Sync Options Tab Control how events sync from TechExcel ServiceWise to Microsoft Outlook with these settings. Only the events that meet the criteria defined here will be synced to Outlook appointments or tasks. 2.Sync options For each event template there are three sync options available: 1. Don t sync 2. Sync to appointment 3. Sync to task 3.Sync Statuses For each event template, the administrator may choose the event statuses in which the event will be synced. 4.Date Range The administrator may define date ranges to further limit event syncing so not all events are synced at once. The Administrator may create Date Range rules based on the event Create Date, Start Date, and End Date. The date range rules are global and will apply to all event templates configured to synchronize with Outlook. Save s as Events Tab End users may save s from Microsoft Outlook to TechExcel ServiceWise as an event. When users choose to save an as an event, they will be able to choose from the events the administrator has selected as applicable event templates. Only event templates with an event type of received or sent (defined in the event template settings) are available to administrators when defining applicable events. A default event template may also be defined by the administrator for the most commonly used event User Configuration Configuring TechExcel Outlook Sync If you have not installed the TechExcel Outlook Sync plug-in, please see the AppendixInstalling TechExcel Outlook Syncfor detailed installation instructions. Page 137 of 145

138 Configuring Outlook Sync for Use 1. Press Configuration Before using TechExcel Outlook Sync, you need to run the Configuration wizard. The wizard will run automatically the first time you open Outlook after installing. You may also run the configuration wizard by pressing the Configuration button in the Outlook toolbar, or selecting the new ServiceWise menu option, and selecting Configuration. 2. Press User Login Enter your TechExcel ServiceWise login credentials, select the correct web service connection, select the project to synchronize s, and press the OK button. Having Trouble Logging In? Do you have permission to use the Outlook Sync? Contact your ServiceWise Administrator to request permission to use Outlook Sync. Does the project you belong to allow for Outlook Sync? Contact your ServiceWise Administrator to inquire if the project allows Outlook integration. Not Seeing Synchronization? Make sure you have selected the correct project in the Select Project dropdown. You may only synchronize with one project at a time. However, you may always return to this configuration screen and switch projects. 3. Press Setup Local DB After you have configured user profile information, the wizard will ask you to set up a local database. Or, you may select thesetup Local DBitem in the Configuration menu. The local database will be used to preferences and also actions performed while offline. When a connection becomes available, the actions performed will synchronize with the live ServiceWise system. To configure your local database Select the Database Type. Choose between: Microsoft Access Microsoft SQL server Page 138 of 145

139 Once you have completed the database connection information, press the OK button. The configuration wizard will populate the local database with the correct tables and synchronize data from live ServiceWise database. 4. Finishing Configuration After the local database is updated, the configuration wizard will display a list of event synchronizations and settings defined by your ServiceWise Administrator. This summary shows the ServiceWise event templates used for synchronizing Outlook events and appointments and also the ServiceWise events created when saving Outlook s to ServiceWise. You may always utilize the Configuration menu to reconfigure local settings. For example, Set up local DB: Create a new or change the local database. Sync time: Re-synchronize the time difference between the local and master database. Restore local DB: Overwrite the local database with data from the live ServiceWise database Using TechExcel Outlook Sync Add an Outbound to ServiceWise When sending an , you may now choose to save the to TechExcel ServiceWise and associate the with a customer and a specific support incident if connected to a support project or sales opportunity if connected to a sales project. 1. Create a new message within Outlook. 2. Press the Add-Ins toolbar or menu item. 3. Press thesend and Save to ServiceWisebutton (Shown in image below). 4. Confirm the Send information is correct or make adjustments using the Save Event dialog (shown below). Page 139 of 145

140 4. Confirm the Send information is correct or make adjustments using the Save Event dialog (shown below). 5. The correct employee will be selected automatically based on the matching information from TechExcel ServiceWise. You may add Employees using thenew buttons next to Employee fields. You may search Employees using theicon next to the Employee field. You may edit the existing information using any of theeditbuttons for the Employee. Please Note:Creating/editing employee information is only available when there is an interment connection. Functions performed offline will be done on the local database and synchronized to main TechExcel ServiceWise database when a connection becomes available. 6. Choose the related incident to associate the event. 7. Choose theevent templateandevent statusused to track this activity in TechExcel ServiceWise. 8. You will now see this event and message from within TechExcel ServiceWise. Please Note: An can only be saved to one event. Once saved, the Save to ServiceWise button will be disabled for that Add a Sent or Received to ServiceWise s already in your Microsoft OutlookInboxorSent Itemsfolders may also be saved to TechExcel ServiceWise retroactively. The steps are similar to those above and the Save Event dialog is the same. 1. Select any you have received or sent within Microsoft Outlook. 2. Press thesave to ServiceWisebutton from the ServiceWise toolbar. 3. Complete the Save Event dialog. Again, you may use this dialog to associate the with the correct customer, contact, incident, and ServiceWise event. You may also create new customer and contact information from this dialog. Please Note: An can only be saved to one event. Once saved, the Save to ServiceWise button will be disabled for that Add an Outlook Task or Outlook Appointment to ServiceWise You may choose to sync an appointment/task to a ServiceWise event. To do so, you will be required to specify the customer and event information using the ServiceWise toolbar visible whenever an Outlook task or appointment is opened Understanding the ServiceWise Outlook Toolbar The toolbar shown below becomes visible whenever an Microsoft Outlook task or appointment is opened: By default, the toolbar is grayed out for a new appointment/task, indicating it will not be synced to a ServiceWise event. The tool bar includes three fields that display the current Project, Employee/Customer and Event information. The toolbar includes two ellipses ( ) buttons you may use to change the associated Employee and Event Info. Clicking either ellipses ( ) button will bring up the dialog below: Page 140 of 145

141 By default, the toolbar is grayed out for a new appointment/task, indicating it will not be synced to a ServiceWise event. The tool bar includes three fields that display the current Project, Employee/Customer and Event information. The toolbar includes two ellipses ( ) buttons you may use to change the associated Employee and Event Info. Clicking either ellipses ( ) button will bring up the dialog below: Synchronizing Events and Appointments 1. If Sync to ServiceWise is not checked, all other fields on the dialog will be disabled. This appointment/task will not sync to a ServiceWise event. 2. To specify the customer/event information, check the Sync to ServiceWise checkbox: 3. When an Employee is selected their information will be displayed. 4. Clicking the New or Edit buttons will begin the create/edit a Employee dialog shown in the image below. Please Note:Creating/editing employee information is only available when there is an interment connection. Functions performed offline will be done on the local database and synchronized to main TechExcel ServiceWise database when a connection becomes available. 5. A quick search dialog is provided for searching Employees. 6. You may choose to associate the event to the incident or opportunity. Only incidents related to the selected customer are displayed. 7. Select the event template and status in the Event Info frame. The events available are based on the status of the related incident selected. If you are using event workflow you will only see events that are applicable to the state of the incident. If no incident is selected, all the event templates will be listed. Page 141 of 145

142 8. The default event owner will be set to the user using Outlook Sync. You may change it to another team member. Please Note: If you create or change the ownership of an appointment/task to another project member it will no longer be available for you to once it is synced to ServiceWise. 9. You must specify a customerandan event template if you want to sync the appointment/task to a ServiceWise event. 10. When an appointment is synced to a ServiceWise event the subject and content will become Event Title and Event Description. The start time and end time of the Outlook appointment/task will become the ServiceWise Event start date and end date Synchronize ServiceWise Events to Outlook Appointments/Tasks This operation happens automatically and there is no user interface involved in this function. When Microsoft Outlook is opened, the TechExcel Outlook Sync begins to compare the live ServiceWise database with your local database. If there are synchronizations required they occur automatically. If there are any changes in the Administration settings or incidents/customers/contacts, the sync service will also sync them to local DB. Therefore the settings for the Outlook integration will be up-to-date as long as there is an interment connection APPENDIX: Installing TechExcel Outlook Sync 1. Download TechExcel Outlook Sync setup (OutlookSynz.zip) from website or a location provided by your TechExcel Administrator. 2. Backup Microsoft Outlook files using Microsoft Outlook backup function. 3. Close Microsoft Outlook 4. Uncompress installation files to a local folder. You will have the following folders and files: 5. Run the setup.exe to install prerequisite program files. 6. Run CWOutlookAddinSetup.msi and follow on-screen prompts 7. Start Microsoft Outlook and continue with the sectionuser Configuration Configuring TechExcel Outlook Syncabove. Chapter 24 Smart Screen Administration 24 Chapter24 -- Smart Screen Administration ]]> Smart Screen helps you manage the many different types of requests a help desk or IT team encounterincluding: incident requests, change requests,service requests, safety reports, and evennon-technical requests and workorders. Specifically, Smart Screen enables you to configure each form with a different layout and different fields so you capture therequired information for the type of request. Smart Screen allows administratorsto design each form for a specific need and presentend users with a clearly defined form and structure.it is easier for end users because theforms may be simplified to includeonly necessary fields which will also improve thecorrect categorization rate of submitted issues. ]]> New Incident Type Field The Incident Type field is a new System Level drop-down field. The labelincident Typemay be renamed. This special drop-down field determines which layout is presented tothe user. Therefore, each UI page the user encounters including the New page, Current Status page, Forward page, Custom pages, and others may be customizedto displayinformation relevant to the Incident Type selected. The Incident Type field is similar to other fieldsand may be used to create escalation,notification, and SLA auto-apply conditionsfor automating incident management. Usersmay also add the Incident Type fieldto their List View and Reports. Page 142 of 145

143 Form Visibility Public or Private Each Incident Type may be configured for use byteam members only or for both teammembers and as an available option within the self-service portal. Overwrite Pages Overwrite pages allow Administrators to design the UI of different Incident Types. An unlimited number of Overwrite pages may be definedallowing for countless layouts andform designs. Each Overwrite page is then linked with an Incident Type. When users select an Incident Type choice, the correct Overwrite page layout is displayed automatically. ]]> Requirements Smart Screen is available in TechExcel ServiceWise or CustomerWise 8.0 or above. Configuring Smart Screens TechExcel System Administrators must enable and configure Smart Screens using the Admin Client. The form fields and layout the user will see is determined by the selection of theincident Typedrop-down field. When a selection is made in the Incident Type field the layout and fields will change immediately based on the user selection. Follow these simple step-by-step instructions to setup multiple forms for your project. Step 1: Determine your Incident Types Do you deal with multiple types of requests and want gather different information based on what type of request it is? If so, Smart Screen may be beneficial to your organization. The first step is to determine the different types of requests your team handles, and if the information required is significantly different for each type of request. Example Scenarios: o Create a different layout for Incident Requests and Enhancement Requests o Create a different layout for Incident Requests and Service Requests o Create a Document Request layout with unique fields and layout Step 2: Create Incident Types in the Smart Screen settings configuration screen Once you have determined the types of forms you will create them as yourincident Typevalues using the Smart Screen Settings page in the Admin client.smart Screen settings are available in the Incident View folder. The values defined will become a drop-down list available to users and technicians. Check thesupport definable screens based on incident typecheckbox to enable Smart Screens. Press the New button, and enter your Incident Type name and visibility. You may always Edit or Delete any Incident Type form configured at a later time. Set the Default Incident Type for team members and customers using the self-service portal. As with other fields in TechExcel, you may change theincident Typelabel to your own terminology. This is done when adding the Incident Type field to the actual form (see next step). Step 3: Change the Incident Type Label (Optional) Page 143 of 145

144 You may customize the Incident Type label to use your town terminology. To do so, on the System Field Design page, select the Incident Type field and press the Design Button. Change the Label. Step 4: Time Saving Tip - Setup the Default Page Layout Before the Overwrite Page Layouts In general, it is easier to setup the default page prior to creating your Overwrite pages because Overwrite pages inherit initial page layout and settings from the default page. You should configure the default page to includefields and layout common to all Overwrite pages. This will help you save time customizing each Overwrite page later because common fields and layout are inherited automatically. For example, in the image below an Administrator may want to configure the default New page (A.) before each Overwrite page (B.) Step 5: Create the form layouts using the Overwrite feature Next, create your page layouts by adding Overwrite pages and customizing each page to meet your needs. You may create Overwrite layouts for each page including the New page, Description page, Current Status page, any Custom page, and any Function page (New, Reopen, Close, Forward). Choose a page you want to create a different layout for and right-click the Overwrite folder. Select Add Page Name the Overwrite Page by double-clicking the page title as shown below. Customize each Overwrite page. Customizing the Overwrite pages is similar to page customization available in previous versions. See the Admin guide for more details on page customization. Step 6: Associate the Overwrite Page with the Incident Type After creating Overwrite pages for different page layouts, you must now associate the layout with the Incident Type choice. When a user selects an Incident Type, the correct Overwrite layout will be displayed. A. On the default page enable Overwrites by selecting thecan Overwriteradio button. B. Incident Types you have defined will be displayed in the type column. Page 144 of 145

145 C. For each Incident Type you may choose which Overwrite page to display using the Page Name drop-down. Please Note: Overwrite pages may be reused, and apply to more than one Incident Type choice. Step 7: Setup Account Type Privileges Administrators may configure which account types have permission to change the Incident Type field after the initial submission. A new account type Incident privilegecan change incident typeis available. This is privilege controlled because changing the Incident Type after submission may change the layout, and possibly the categorization, of the incident. Step 8: Optional Link your Incident Type Layouts with Templates If using Templates for incident submission, you may now choose to use Incident Type field in conjunction with template design. Since Incident Type is available as a predefined field you may automatically set he layout of the submission screen by choosing an Incident Type choice in your template. ]]> To the end-user, Smart Screen may appear as just an additional field: Incident Type. However, whenever a selection is made in the Incident Type field, the for Page 145 of 145