ServiceWise Admin Guide
  • Author:TechExcel co.Ltd
  • Date:
Table of Content
ServiceWise Admin Guide
TechExcel ServiceWise Admin Guide
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.

1.1 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.)

1.2 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.

1.3 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.

2 ServiceWise Administration

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.)

2.1 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 Email 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.

2.2 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

• Incident definition and GUI customization

• Project member administration

• Workflow administration

2.3 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.

3 Team Representation and Management

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.

3.1 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.

3.2 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.

3.3 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.

4 Incident and Event 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.

4.1 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 email notifications, or personalized incident summaries by email.

4.2 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 email notifications for all escalations.

4.3 Incident Escalations

ServiceWise incident notification enables support teams to ensure that all appropriate stake holders are notified (by email, 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 emailandpull emailfor each incident notification rule using subscription rules. Project administrators 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.

4.4 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 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.

4.5 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 email notifications. incident escalation

Project teams may be notified by email, 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.

4.6 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.

4.6.1 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 email, or approval from management.

5 Employee Management

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.

5.1 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.

5.2 Tracking Email

Communication by email between support engineers and employees is represented in ServiceWise project by email 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 email from an employee. All email events are instances of an administrator-defined event template belonging to one of three event types:

• The Email Sent event type represents a set of business rules for managing email sent to an employee from a ServiceWise project member.

• The Email Received event type represents a set of business rules for managing email sent to a project member from an employee.

• The Email Announcement event type represents a set of business rules for managing email announcement events.

5.3 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 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.

5.4 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.

6 Knowledge Management and Communication

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 Email 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.

6.1 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-to-date 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.

6.2 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.

6.3 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 email.

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

7 Asset Management

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

• Incident definition and GUI customization

• Project member administration

• Workflow administration

7.1 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.

• 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.

7.2 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.

7.3 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.

7.4 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.

8 Professional Services Management

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.

8.1 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

8.2 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.

9 ServiceWise Add-On Modules

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

9.1 TechExcel ServiceWise LinkPlus

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

10 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 Email 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.

11 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.

11.1 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.

11.2 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.

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.

11.3 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 E-mail Queries

• Auto Routing settings

• Knowledge view settings

• E-mail 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 E-mail Queries

• Auto Routing settings

• Knowledge View settings

• E-mail 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.

11.4 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.

11.5 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.

11.6 Inactive projects

Inactive ServiceWise projects may be deleted using the Delete Project command in the File menu. Active projects cannot be deleted.

11.7 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.

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.

11.8 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.

11.9 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.

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.

11.10 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.

12 Managing Solution Templates

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.

12.1 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.

12.2 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.

12.3 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.

13 Running the Go Live Wizard

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.

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.

14 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 email 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

• Emailing the ServiceWise Installer to Project Members

14.1 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:

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.

14.2 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 email 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.

14.3 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, email, 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.

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.

14.4 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, email, 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.

Email:The Email property may be used to store the email address of project members.

14.5 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.

14.6 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.

14.7 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.

14.8 Emailing the ServiceWise Installer to Project Members

System administrators may use the Email the Selected Users for Client Installation button to email 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 email 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 Email the Selected Users for Client Installation button.

14.9 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”.

15 Defining Team Member Contact Information

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:

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.

15.1 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.

15.2 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 email address.The secondary email 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.

15.3 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.

15.4 Defining User Account Email Signatures

An signature is a brief message that is automatically added to the bottom of email messages sent from a ServiceWise project. Signatures frequently display the name, job title, phone number, and other contact information of the email sender. Signatures may also be used to add boilerplate paragraphs to all outgoing email messages.

Administrator-defined user account signatures are unique signatures that are appended to all email 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 email template signatures are signatures that are appended to email messages manually sent by project members from within the ServiceWise client. System administrators may define three different email templates: the Incident Email template, the Resend Email template, and the Reply Email template. Each email template may have a unique signature.

• Notification email template signatures are signatures that are appended to email messages that are automatically sent from a ServiceWise project based on administrator-defined email notification rules.

The signature displayed in an outgoing email depends on administrator-defined email notification configurations.

To enable and define ServiceWise user account signatures:

1Select the Team Member Email Address Assigned to the Team Member option in the Default Reply Email Address dropdown list of the General Settings tab of the Email Integration page.

The administrator-defined email signature overwrites both manual template signatures and notification email 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 Email Signature control of the Advanced tab in the Member Information manager.

4Click the OK button.

16 Importing and Exporting User Accounts

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 email 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.

16.1 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.

16.2 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 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.

16.3 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.

17 Administering System Team Groups

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, email, 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.

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.

17.1 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.

17.2 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.

18 Administering User Logins

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, email, 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.

Email:The Email property may be used to store the email address of project members.

19 Administering User Licensing

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.

19.1 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.

20 Managing Administrator Account Types and Access Controls

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.

20.1 Creating System Administrator Account Types

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

21 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, email 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

21.1 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 8229.

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 8118.

6 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.

21.2 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.

21.3 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.

21.4 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.

22 Administering Email Error Handling

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 8229.

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 8118.

6 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.

22.1 Defining General Email 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 email trace level and email service settings.

Email trace levels determine the types of messages that are logged when email errors occur. System administrators may choose one of three email trace settings:

• The Info, Warning, and Error trace level

• The Warning and Error trace level

• The Error trace level

Email service settings determine the sensitivity of the email notification service. Email 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 Email Trace Level dropdown list.

3Select an option from the Email Service Setting dropdown list.

22.2 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 Email 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.

22.3 Define Email Service Messages

System administrators may enable email notification of service messages and define service message properties using tools in the Mail Notification Service Error Handling Setting manager.

Email notification service messages are delivered when email handling error occur with the email notification service.

• The SMTP server name

• Require authentication

• Email recipient and sender addresses

• The email log level

• The time interval

To define email service messages:

1Select the Email Retrieval page in the Mail Error Handling folder in the System Settings view of the ServiceWise Admin client.

2Select the Email 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 email address for service message recipients in the Email Recipients field.

6Define the email address for service message senders in the Email Senders field.

7Select an option from the Email Log Level dropdown list.

8Select an option from the Time Interval for Sending Log dropdown list.

22.4 Defining Email Service Error Reports

System administrators may use the Email Notification Error Service Handling Setting manager to define email notification error reports.

If an email notification message is not delivered to any selected recipients, the sender automatically receives an error report email and email attachment that explains why the email notification was not delivered.

System administrators can define the recipient, sender, the level of detail, and the time interval of the email service error report email in the Email Notification Error Service Handling Setting manager.

To define email error report settings:

1Select the Email Retrieval page in the Mail Error Handling folder in the System Settings view of the ServiceWise Admin client.

2Inthe General Settings area, define the Email 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 email notification service messages check box.

5Define the SMTP Server Name.

6Enter the email address of the error report recipient in the Email Recipient Address field.

7Enter the email address of the error report sender in the Email Sender Address field.

8Select the scope of the error report by selecting an option from the Email Log Level dropdown list.

9Select a time interval for the error report emails by selecting an option from the Time Interval for Sending log dropdown list.

10Select the OK button.

23 Administering LinkPlus Integration

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.

24 Administering System Messages

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.

24.1 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.

24.2 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.

24.3 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 16.

25 Administering System Time Zones and Time and Date Formats

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.

25.1 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

25.2 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.

26 Administering CTI Integration

ServiceWise email error handling enables system administrators to track and diagnose problems with incoming and outgoing email notifications. All email error handing settings are defined in the System Settings project. System-level settings apply to all project in a ServiceWise site.

Email retrieval and email notification settings are defined separately.

• The Email Retrieval page enables system administrators to define rules for managing incoming email errors.

• The Email Notification page enables system administrators to define rules for managing outgoing email errors.

Figure 4-1: Email Retrieval Page

Using the Email Retrieval page and the Email Notification page in the System Setting page, system administrators may define general settings including trace levels for email notification errors, create error logs, and define email notification service messages.

26.1 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.

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:

http://localhost/scripts/texcel/helpdesk/helpdesk.dll 

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.

26.2 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

26.3 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.

26.4 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.

27 Administering the TechExcel Search Engine

System administrators may define general mail error handling settings using tools in the Mail Notification Service Error Handling Setting manager. General settings include the email trace level and email service settings.

Email trace levels determine the types of messages that are logged when email errors occur. System administrators may choose one of three email trace settings:

• The Info, Warning, and Error trace level

• The Warning and Error trace level

• The Error trace level

Email service settings determine the sensitivity of the email notification service. Email 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 Email Trace Level dropdown list.

3Select an option from the Email Service Setting dropdown list.

27.1 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.

27.2 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.

27.3 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.

28 Managing ServiceWise Admin Reports

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 Email 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.

29 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

29.1 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.

 

29.2 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.

 

29.3 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.

29.4 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.

30 Managing Project Properties

 

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.

 

30.1 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:/ \ : ? “ < > |.

 

30.2 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.

30.3 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.

.

30.4 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.

 

30.5 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.

 

30.6 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.

 

30.7 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.

 

30.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

30.9 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.

 

30.10 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.

30.11 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.

 

30.11.1 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

30.11.2 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:Any 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.

.

30.12 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.

 

30.13 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.

30.14 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-mail (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.

30.15 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.

31 Managing Optional Project Features

 

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.

 

31.1 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.

31.2 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 E-mail 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

32 Managing Project Administrators

 

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.

32.1 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.

33 Managing Account Types

 

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.

33.1 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

33.1.1 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.

33.1.2 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.

 

33.1.3 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.

 

33.2 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.

33.3 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 being added to a project.

 

 

33.4 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.

33.5 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.

34 Managing Account Access Controls

 

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 100.

35 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-by-project basis.

35.1 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.

35.2 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

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.

35.3 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.

36 Configuring General Support Incident Properties

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.

36.1 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.

36.2 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.

36.3 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.

36.4 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.

37 Administering Controls

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

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.

37.1 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

37.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

37.3 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.

37.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

37.5 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.

37.6 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.

37.7 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

37.8 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

37.9 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.

37.10 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.

37.11 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.

37.12 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.

37.13 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.

6Click the OK button.

The ServiceWise dialog box closes.

37.14 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.

37.15 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

37.16 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.

• 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

37.17 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

37.18 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.

37.19 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.

37.20 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

37.21 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

37.22 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.

37.23 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.

38 Administering System Pages

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.

38.1 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.

38.2 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.

38.3 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

38.4 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

38.5 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.

38.6 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.

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.

38.7 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.

39 Administering Custom Pages

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

39.1 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

40 Administering Function Pages

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.

41 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

41.1 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.

41.2 Defining Referential Link Types

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.

41.3 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.

42 Managing the Web Conversation Page

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.

43 Administering Incident Workflow State Display Order

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.

44 Managing Incident Priority

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.

44.1 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.

44.2 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.

44.3 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.

44.4 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.

44.5 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.

44.6 Granting Incident Prioritization Access Controls

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.

45 Administering the Change Log

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 email 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 Email option

Project administrators must enable support for the Web Conversation feature in the Project Properties page. Web conversations are enabled in each project independently.

46 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.

46.1 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.

47 Enabling and Configuring Interproject Copying 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.

47.1 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.

47.2 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.

47.3 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.

47.4 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.

47.5 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.

47.6 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.

47.7 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

47.8 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

47.9 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 check mark appears next to the project title.

2Enter a text string in the Title Prefix Concatenated text box.

47.10 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.

47.11 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.

48 Mapping Incident Property Fields

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

• 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

48.1 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.

48.2 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.

48.3 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.

• 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.

48.4 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.

49 Administering Linked Issue Employee Web Portal Settings

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.

49.1 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 424.

49.2 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.

49.3 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.

49.4 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.

49.5 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.

49.6 Adding Linked Issue Information Fields

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.

50 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 email 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.

51 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

51.1 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.

51.2 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.

51.3 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.

51.4 Defining Applicable Owner Workflow Rules

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.

51.5 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.

51.6 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:

{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.

51.7 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.

51.8 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.

51.9 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 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.

51.10 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.

51.11 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

52 Designing ServiceWise Graphical Workflow

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.

52.1 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.

52.2 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.

52.3 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.

52.4 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.

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.

52.5 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.

52.6 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.

52.7 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.

52.8 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.

52.9 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.

53 Administering Incident Routing

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.

53.1 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.

53.2 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.

53.3 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.

53.4 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.

53.5 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.

53.6 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.

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.

53.7 Defining 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.

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.

54 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.

 

54.1 Administering Subprojects

 

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

 

55 Defining General Subproject Settings

 

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

 

55.1 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.

 

55.2 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.

55.3 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.

55.4 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.

 

55.5 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.

 

55.6 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.

 

55.7 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.

 

55.8 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.

 

55.9 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.

 

56 Administering Subproject Status Definitions

 

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

56.1 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.

 

56.2 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 highest-ranking status determines the status of the subproject.

 

56.3 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.

 

56.4 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.

 

56.5 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 highest-ranking status determines the status of the subproject.

 

57 Defining Subproject Priorities

 

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.

 

57.1 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.

 

57.2 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.

 

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 highest-ranking priority determines the priority of the subproject.

 

57.3 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.

 

57.4 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.

 

57.5 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 highest-ranking priority determines the priority of the subproject.

 

58 Defining Subproject Access Controls

 

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.

59 Understanding ServiceWise Email Integration

Email integration enables ServiceWise support teams to better manage project incidents, events, and employees by automating and tracking communication conducted by email.

Using controls in the Advanced Settings folder, project administrators may enable and define email-based tools that enable project members to work together more effectively.

ServiceWise email integration is a prerequisite for the following features:

•Email event trackingenables support teams to track every email sent to and received from employees through the ServiceWise client asevents. All email events are based on administrator-defined email received or email sent event templates.

• Project support formultiple incoming email addressesenable support teams to better manage and distribute email requests from employees. Each project may support multiple team email accounts, personal email addresses, and personal email aliases. The “reply to” address in project email may be based on the team email account assigned to the support engineer sending the email or the team email account assigned to the employee that received the email.

•Email autoreplyenables support teams to define rules for automatically sending predefined email to employees whenever an email is received from that employee.

•Incident autosubmissionenables project members and employees to submit incidents to ServiceWise projects by email. ServiceWise automatically creates new incidents based on the content of the subject line and body of the email.

•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 Email Notification page of the Advanced Settings folder.

59.1 Understanding System-Level Email Integration

System-level email integration administrative tasks must be completed before project administrators may configure and define project email integration settings.

System administrators are responsible for installing the ServiceWise Email Server service, the ServiceWise Email Retrieval service, and configuring the ServiceWise environment to operate properly. System administrators are also responsible for defining email error handling rules.

System administrators must install the ServiceWise Email Server and start the email notification service to enable project administrators to implement incident notification in ServiceWise projects.

System administrators may install the ServiceWise Email 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.

• ServiceWise Database Server and ServiceWise Application Server must be installed before ServiceWise Email Server can execute properly.

• The ServiceWise Email Server may be installed on an existing mail server as long as it is MAPI and SMTP compliant.

When the ServiceWise Email 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 Email Server communicates with the ServiceWise Database Server and sends email messages through a POP3 or SMTP mail server:

• The ServiceWise Email Server then talks to the ServiceWise Database Server and queries the ServiceWise database for email messages that must be sent.

• When the ServiceWise Email Server finds email messages to be sent, it talks to a POP3/SMTP mail server and send out the emails through that mail server.

• After it has sent the email messages, the ServiceWise Mail Server resets flags in ServiceWise Database.

• The ServiceWise Email service continues to query the ServiceWise database for new email messages that need to be delivered.

59.2 Understanding Email Events and Event Templates

Email event tracking enables support teams to track every email sent to and received from employees through the ServiceWise client as events. All email events are based on administrator-defined email received or email 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 email notification and escalation rules.

Email event templates may be based on one of two email event types: the email received event type and email send event type. In ServiceWise an event type represents a task and are managed by a set system-defined business rules.

• Email received event templates combine administrator-defined workflow rules with system-defined business rules for managing email received events.

• Email sent event templates combine administrator-defined workflow rules with system-defined business rules for managing email sent events.

In ServiceWise, email events —instances of email event templates—are automatically created in a work project whenever an email is received by or send from a team email account.

Project administrators may create multiple email received event templates and multiple email sent event templates. Every team email account may be assigned a unique set of email event templates, with unique owners, due dates, and workflow. The email templates assigned to that team email account are used to automatically create email events whenever an incoming email is received or sent from the team email account.

• An email received event based on an email received event template is created automatically whenever an employee sends an email to the support team.

• An email sent event based on an email sent event template is automatically created whenever a ServiceWise project member sends an email to an employee.

60 Managing Incoming Mail Server Settings

System-level email integration administrative tasks must be completed before project administrators may configure and define project email integration settings.

System administrators are responsible for installing the ServiceWise Email Server service, the ServiceWise Email Retrieval service, and configuring the ServiceWise environment to operate properly. System administrators are also responsible for defining email error handling rules.

System administrators must install the ServiceWise Email Server and start the email notification service to enable project administrators to implement incident notification in ServiceWise projects.

System administrators may install the ServiceWise Email 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.

• ServiceWise Database Server and ServiceWise Application Server must be installed before ServiceWise Email Server can execute properly.

• The ServiceWise Email Server may be installed on an existing mail server as long as it is MAPI and SMTP compliant.

When the ServiceWise Email 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 Email Server communicates with the ServiceWise Database Server and sends email messages through a POP3 or SMTP mail server:

• The ServiceWise Email Server then talks to the ServiceWise Database Server and queries the ServiceWise database for email messages that must be sent.

• When the ServiceWise Email Server finds email messages to be sent, it talks to a POP3/SMTP mail server and send out the emails through that mail server.

• After it has sent the email messages, the ServiceWise Mail Server resets flags in ServiceWise Database.

• The ServiceWise Email service continues to query the ServiceWise database for new email messages that need to be delivered.

60.1 Enabling Email Autoretrieval in ServiceWise Projects

ServiceWise projects use the TechExcel ServiceWise Mail Retrieval Server, an NT service, to retrieve email from an email server using the POP3 or MAPI protocol.

To enable and execute email 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 email service must be started.

• The Support Email Autoretrieval check box must be selected in the Incoming Mail tab of the Email Integration page.

Once started and enabled, the TechExcel Mail Retrieval Server communicates with a designated incoming email server and establishes an authorized connection with that server using the user name and password defined in a team email account. The Mail Retrieval Server then retrieves email addressed to that account.

Project administrators may create multiple team email accounts and each of those team email accounts may connect to a different email server using a unique POP3 or MAPI email account.

To enable email autoretrieval in the current project, select the Support Email Autoretrieval check box in the Incoming Mail tab of the Email Notification page in the Advanced Settings folder.

Note:The Support Email Autoretrieval check box is grayed out if advanced email integration is not enabled in the project. For more information see See “Managing Optional Project Features” on page 106.

60.2 Enabling Multiple Team Email Accounts

ServiceWise advanced email integration enables projects to support multiple incoming email servers and team email accounts.

Project administrators may define multiple team email accounts in each ServiceWise project, and each team email account may connect to a different incoming email server using its own user name and password.

Support teams may wish to use different team email accounts to manage email messages regarding the various products, services, or locations that are managed by ServiceWise support engineers.

• Each team email account has a uniqueemail address, and the email address assigned to a team email account may indicate the product, service, or location served by that email account.

• Each support project member is assignedoneteam email account in each ServiceWise project. Multiple team email accounts enable support teams to divide workload across team members based on their expertise, job role, or location.

• Each team email account represents two administrator-defined event templates: an email received event template and an email sent event template. Email messages sent to or from a team email account automatically create email events based on the corresponding email received or email 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 Email Notification page in the Advanced Settings folder.

Note:The Support Multiple Team Email Addresses check box is grayed out if advanced email 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 email accounts, he or she may defined multiple team accounts in the Edit Email Property manager of the Incoming Mail tab of the Email Integration tab.

60.3 Defining Team Email Accounts

A team email account bundles together a POP3 or MAPI email account (an incoming email server, email address, user name, and password) with two administrator-defined email event templates.

A project administrator may define one or more team email accounts in each ServiceWise project.

• If standard email integration is used in a ServiceWise project, the project administrator defines a single team email account that connects to a single incoming email server. All support engineers in the project share a common team email address: for example,support@abcsoft.com.

• If advanced email integration is used in a ServiceWise project, the project administrator may define multiple team email accounts that connect to many different incoming email servers. Support engineers may be defined different team email accounts based on their expertise, job role, location, or any other criteria that makes sense to the business.

Project administrators may define team email accounts using Edit Email Property manager in the Incoming Mail tab of the Email Integration page of the Advanced Settings folder.

The email address represented by the team email account is only used when project members reply to email messages send by employees that have not been assigned team email accounts. Employees may be assigned team email accounts based on their employee type. For more information see  “Defining Reply To Email Addresses based on Employee Types”.

To create team email accounts:

1 Optional: To define multiple team email accounts, select the Support Multiple Team Email Account check box in the Incoming Mail tab of the Email Integration page.

2Click the New button in the Team Email Accounts area of the Incoming Mail tab of the Email Integration page.

The Edit Email Property manager appears.

3Choose an email protocol for communicating with the incoming email server.

ServiceWise supports two protocols for retrieving email 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 Email 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 Email Server Settings” .

4Select a default email received event template in the Default Event Template for Email Received dropdown list.

The Default Event Template for Email Received dropdown list displays all of the event templates created in the project that are based on the Email Received event type.

Email sent to the team email address automatically create events based on the selected event template.

Note:Project administrators must define at least one email received event template for ServiceWise email integration to work. For more information on the email received event type see See “Project administrators may create multiple event templates based on the E-mail Received event type in the Event Templates page of the Event Management folder in the ServiceWise Admin client.”.

5Select a default email sent event template in the Default Event Template for Email Sent dropdown list.

The Default Event Template for Email Sent dropdown list displays all of the event templates created in the project that are based on the Email Sent event type.

Email sent from the team email address automatically create events based on the selected event template.

Note:Project administrators must define at least one email sent event template for ServiceWise email integration to work. For more information on the email received event type see See “Managing E-mail Sent Event Templates”.

6Click the OK button.

60.4 Defining POP3 Email Server Settings

Project administrators may define unique POP3 email account whenever they create a team email account in ServiceWise.

Each team email account bundles together POP3 email protocol settings (an incoming email server, email address, user name, and password) with two administrator-defined email event templates.

To create POP3 team email accounts:

1 Optional: To define multiple team email accounts, select the Support Multiple Team Email Account check box in the Incoming Mail tab of the Email Integration page.

2Click the New button in the Team Email Accounts area of the Incoming Mail tab of the Email Integration page.

The Edit Email 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 email address.

The Account Information requires a predefined email account along with its

matching password for the mail server.

• Email address

• account name

• user name

• password

6Define the event templates.

7Define the default reply-to address.

60.5 Defining MAPI Email 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 email from a Microsoft Exchange Server. Each MAPI profile represents a set of user information (user name and email address), email server information, and login information (user name and password) that are defined and stored in a domain.

To configure ServiceWise email retrieval using the MAPI protocol, project administrators must define MAPI profiles on the email server machine and identify those MAPI profiles in appropriate project team email accounts.

All team email accounts are defined in the Incoming Email tab of the Email Notification page. Team email accounts bundle together an email protocol (POP3 or MAPI) with two administrator-defined email event templates (an email received event template and an email sent event template).

To define MAPI email server settings for team email 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 email address.

• Define the server information.

• Define login information including the user name and password.

2Install a Microsoft Outlook client (or another MAPI-compliant email client) on the same machine as the one running the TechExcel Email Retrieval Server service.

The email 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 email client.

4Log into the Microsoft Outlook client using the MAPI profile.

5Ensure that the MAPI profile may send and receive email using the Microsoft Outlook client.

6Create a team email account in the ServiceWise Admin client.

The TechExcel Email Retrieval Server uses the MAPI profile identified by the team email account to log into the Microsoft Exchange Server and retrieve incoming email.

60.6 Defining the Reply-to Address of Outgoing Email

Project administrators may define an email address as the default “reply to” address for all incoming project email.

To define the default “reply to” email address for email sent from the ServiceWise project, select an option from the Default Team Email Address dropdown list in the Incoming Mail tab of the Email Integration page in the Advanced Settings folder.

The Default Team Email Address dropdown list displays every administrator-defined team email account created in the project.

The default email address for email reply is the “reply to” address that is used if no other email address is acceptable.

The sending address for these replies to employee email may be one of three email 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 email is the “reply to” designated in the team email address that is assigned to the project member.

• The sending address used for replies to incoming email may be based on “reply to” designated in the team email address assigned to the employee that sent the original email. Employees may be assigned team email accounts based on their employee type. For more information see “Defining Reply To Email Addresses based on Employee Types” .

• The default “reply to” address is only used if two conditions are met: The default email address defined in the General Settings tab of the Email Integration page is set to the Team Email Address Based on Employee Type option and the employee sending the incoming email has not been assigned a team email account.

60.7 Defining Reply To Email Addresses based on Employee Types

In ServiceWise projects, project members may quickly reply to all project email sent by employees regarding ServiceWise incidents.

The sending address of reply emails may be based on one to three administrator-defined email 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 email address defined in the General Settings tab of the Email Integration page is set to the Team Email Address Based on Employee Type option.

• The employee that sent the original email (the email that the project member is replying to) is assigned a team email address based on their account type.

In this configuration, the “reply to” address displayed in the email sent to employees is not based on the team email address assigned to the project member, but the team email address assigned to the employee type of the employee receiving the email.

To define team email addresses based on employee types:

1Click the Team Email Addresses for Customers button in the Incoming Mail tab of the Email Integration page in the Advanced Settings folder.

The Team Email Addresses for Customers dialog box appears.

2Double-click an employee type in the Employee Type list.

The Define Email Address for Employee Type dialog box appears.

3Select an administrator-defined team email account and click the OK button.

The email address is assigned to the employee type.

4Click the OK button.

61 Managing Project Sending and Reply-to Addresses

Email event tracking enables support teams to track every email sent to and received from employees through the ServiceWise client as events. All email events are based on administrator-defined email received or email 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 email notification and escalation rules.

Email event templates may be based on one of two email event types: the email received event type and email send event type. In ServiceWise an event type represents a task and are managed by a set system-defined business rules.

• Email received event templates combine administrator-defined workflow rules with system-defined business rules for managing email received events.

• Email sent event templates combine administrator-defined workflow rules with system-defined business rules for managing email sent events.

In ServiceWise, email events —instances of email event templates—are automatically created in a work project whenever an email is received by or send from a team email account.

Project administrators may create multiple email received event templates and multiple email sent event templates. Every team email account may be assigned a unique set of email event templates, with unique owners, due dates, and workflow. The email templates assigned to that team email account are used to automatically create email events whenever an incoming email is received or sent from the team email account.

• An email received event based on an email received event template is created automatically whenever an employee sends an email to the support team.

• An email sent event based on an email sent event template is automatically created whenever a ServiceWise project member sends an email to an employee.

61.1 Enabling Team Reply-to Addresses

Project administrators may enable the use of team addresses as the “reply to” email address in project email in the General Settings tab of the Email Integration page of the ServiceWise Admin client.

A team email account address is a standard email address that is used by all support engineers assigned to a particular team email account. Every project member may be assigned the team email account that best represents their role in the project. Project administrators may create multiple team email accounts to represent different groups, locations, products, titles, or any other criteria they choose. A typical team email address issupport@abcsoft.com.

Team email addresses may be based on two different options:

• The Team Email Account Assigned To Project Member option identifies the team email account assigned to the project member as the default “reply to” address for project email.

• The Team Email Address Based on Employee Type option identifies the team email account assigned to the employee as the default “reply to” address for project email based on their employee type.

61.2 Enabling Personal Email Addresses as Reply-to Addresses

In ServiceWise, a personal email address represents the personal email address of a ServiceWise user as defined and managed in the base project by a system administrator.

Project administrators may enable personal email addresses to be used as “reply to” email addresses in the General Settings tab of the Email Integration page of the ServiceWise Admin client.

“Reply to” addresses may be based on four different factors: personal email accounts, personal email aliases, team email accounts assigned to support engineers, or team email accounts assigned to employees based on their employee type.

To enable personal email address reply-to addresses:

1Enable advanced email settings in the Optional Settings page of the General Project Settings folder.

If Advanced Email Integration has not been enabled, the advanced email settings controls are grayed out in the General Settings tab of the Email Integration page. For more information see See “Managing Optional Project Features” on page 106.

2Select the Support Personal Email Address check box in the General Settings tab of the Email Integration page.

If the Support Personal Email Address option is not enabled, all email sent to employees from within the ServiceWise client uses a team email account as the “reply to” address.

3Select the Project Member Email Address Defined in Support Member Manager option from the Default Reply Email Address dropdown list.

The Project Member Email Address Defined in Support Member Manager option defines the email sending address as the personal email address of the project member as defined in the Support Member manager.

Project administrators may define project member account types, team email address, and personal email address in the Project Member Properties dialog box of the ServiceWise Members page. For more information see  “Understanding Project Member E-mail Addresses”.

61.3 Enabling Personal Email Aliases as Reply-to Addresses

Project administrators may enable the use of personal email aliases as the reply to email addresses in project email in the General Settings tab of the Email Integration page of the ServiceWise Admin client.

A personal email address represents the personal email address of a support engineer or an email alias that is displayed as a personal address in email (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 email settings in the Optional Settings page of the General Project Settings folder.

If Advanced Email Integration has not been enabled, the advanced email settings controls are grayed out in the General Settings tab of the Email Integration page. For more information see See “Managing Optional Project Features” on page 106.

2Select the Support Personal Email Address check box in the General Settings tab of the Email Integration page of the Advanced Settings folder.

If the Personal Email Address (Alias) option is not enabled, all email sent to employees from within the ServiceWise client use the project member’s team email address as the reply-to address. Project administrators may define a project members account type, team email address, and personal email address in the Project Member Properties dialog box within the ServiceWise Members page. For more information see See “Understanding Project Member E-mail Addresses” on page 121.

3Select the Personal Email Address Defined in this Project option from the Default Reply Email Address dropdown list.

The TechExcel ServiceWise Personal Email Address (Alias) option identifies the project member personal email address (alias) as the reply email address. The project members personal email address in TechExcel ServiceWise is defined as an alias of the team email address. The TechExcel ServiceWise Personal Email Address (Alias) option is only displayed in the Default Reply Email Address dropdown list if advanced email integration is enabled in a project.

61.4 Enabling Personalized Email Reply Name

To enable project members to define a personalized name for replies to project email, select the Enable Personalized Email Reply Name check box.

61.5 Enabling Project Members to Choose Reply Addresses

Project administrators may enable project members to choose whether the email they send to employees from within the ServiceWise client include the standard team email address assigned to them or their personal email address.

To enable project members to choose whether to use their team email account address or their personal email address as the “reply to” address for email sent to employees, select the Allow Project Members to Choose Reply Address when Sending Emails check box in the General Settings tab of the Email Integration page.

If the Allow Project Members to Choose Reply Address when Sending Emails check box is not selected, the default reply address is used.

61.6 Defining Email Notification Send From Properties

Project administrators may define the name of the sender and the sending address of email notification messages using controls in the General Settings tab of the Email Integration page.

• The From Address field enables the administrator to define the address that is displayed in the email client as the originating address of all email notifications.

• The From Name field enables the administrator to define the name that is displayed in the email client as the sender of all email notifications.

62 Managing the Outgoing Mail Server

Incoming email settings determine how email sent to project team email accounts are handled by the ServiceWise system. Incoming email are email messages sent to the team email accounts defined in a ServiceWise project.

Team email accountsbundle a POP3 or MAPI email account (an incoming email server, email address, user name, and password) with administrator-defined default email event templates. Email messages sent to or from a team email account automatically create a email events based on the corresponding email received or email sent event template.

Project administrators may enable and define one or more incoming email servers, enable the retrieval of incoming email from the email server, define one or more team email accounts, and define the default event templates for email received and email sent in the ServiceWise client using controls in the Incoming Mail tab of the Email Integration page in the Advanced Settings folder.

The incoming email configurations and rules that may be defined in a project, and the data-entry controls displayed in the Incoming Mail page of the Email Integration page depend on whether the project is using standard email integration or advanced email integration.

• If advanced email integration is enabled, project administrators may define multiple incoming email servers and multiple team email accounts. Unique email received event templates and email sent event templates may be defined for each team email account.

• If advanced email integration is not enabled, project administrators may defineoneincoming mail server andoneteam email account. All incoming email generate events based on the same email received event template or email sent event template.

Incoming email server settings include:

• Enabling Email Autoretrieval in ServiceWise Projects

• Enabling Multiple Team Email Accounts

• Defining Team Email Accounts

• Defining POP3 Email Server Settings

• Defining the Reply-to Address of Outgoing Email

• Defining Reply To Email Addresses based on Employee Types

63 Managing Email Templates for Manual Email Messages

ServiceWise projects use the TechExcel ServiceWise Mail Retrieval Server, an NT service, to retrieve email from an email server using the POP3 or MAPI protocol.

To enable and execute email 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 email service must be started.

• The Support Email Autoretrieval check box must be selected in the Incoming Mail tab of the Email Integration page.

Once started and enabled, the TechExcel Mail Retrieval Server communicates with a designated incoming email server and establishes an authorized connection with that server using the user name and password defined in a team email account. The Mail Retrieval Server then retrieves email addressed to that account.

Project administrators may create multiple team email accounts and each of those team email accounts may connect to a different email server using a unique POP3 or MAPI email account.

To enable email autoretrieval in the current project, select the Support Email Autoretrieval check box in the Incoming Mail tab of the Email Notification page in the Advanced Settings folder.

Note:The Support Email Autoretrieval check box is grayed out if advanced email integration is not enabled in the project. For more information see See “Managing Optional Project Features” on page 106.

63.1 Managing the Incident Email Template

The Incident Email email template is a predefined email messages that support engineers may use to create incident email messages in the ServiceWise client applications.

Project administrators may define an Incident Email email template in the Email 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 Email template that represent various incident properties.

Whenever an email is created based on the Incident Email email template, appropriate incident property values are substituted for the system variables in the body of the email 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)

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 email template:

1Click the Incident Email button in the in the Email Integration page of the Advanced Settings folder in the ServiceWise Admin client.

The Email Notification manager appears.

2Define the default title of the email template.

3Define a header for the email body of the email template.

4Define the body of the email template.

5Define the signature of the email template.

The Email Signature control enables administrators to define a standard signature to attach to all emails sent from the current project.

6Click the OK button.

63.2 Managing the Resend Email Template

The Resend email template is a predefined email message that serves as a template for creating resend email messages in the ServiceWise client applications.

Project administrators may customize the resend email template in the Email Integration page of the Advanced Settings folder in the ServiceWise Admin client.

Project administrators may customize the email body header and email signature of the resend email template.

To customize the resend email template:

1Click the Email Resend button in the in the Email Integration page of the Advanced Settings folder in the ServiceWise Admin client.

The Header and Signature manager appears.

2Define a header for the email body of the email template.

3Define the signature of the email template.

4Click the OK button.

63.3 Managing the Reply Email Template

The Reply email template is a predefined email message that serves as a template for creating reply email messages in the ServiceWise client applications.

Project administrators may customize the reply email template in the Email Integration page of the Advanced Settings folder in the ServiceWise Admin client.

Project administrators may customize the email body header and email signature of the reply email template.

To customize the reply email template:

1Click the Email Reply button in the in the Email Integration page of the Advanced Settings folder in the ServiceWise Admin client.

The Header and Signature manager appears.

2Define a header for the email body of the email template.

3Define the signature of the email template.

4Click the OK button.

64 Administering Email Incident Submission Settings

ServiceWise advanced email integration enables projects to support multiple incoming email servers and team email accounts.

Project administrators may define multiple team email accounts in each ServiceWise project, and each team email account may connect to a different incoming email server using its own user name and password.

Support teams may wish to use different team email accounts to manage email messages regarding the various products, services, or locations that are managed by ServiceWise support engineers.

• Each team email account has a uniqueemail address, and the email address assigned to a team email account may indicate the product, service, or location served by that email account.

• Each support project member is assignedoneteam email account in each ServiceWise project. Multiple team email accounts enable support teams to divide workload across team members based on their expertise, job role, or location.

• Each team email account represents two administrator-defined event templates: an email received event template and an email sent event template. Email messages sent to or from a team email account automatically create email events based on the corresponding email received or email 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 Email Notification page in the Advanced Settings folder.

Note:The Support Multiple Team Email Addresses check box is grayed out if advanced email 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 email accounts, he or she may defined multiple team accounts in the Edit Email Property manager of the Incoming Mail tab of the Email Integration tab.

64.1 Defining Employee Groups

An email incident submission rule defines the rules that enable a group of employees to submit support incidents to a ServiceWise project by sending an email messages to an applicable team email account.

An employee group represents a set of email 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 email 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 email 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 Email 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 email addresses in the Email Addresses edit box control.

A team email account represents an administrator-defined email account and an email event template. For more information see “Defining Team Email Accounts” .

Note:

5 Optional:To enable incident autocreation from email incident submissions.

Email auto submission automatically create incidents based on email received from applicable employees.

6To enable email field mapping, select this to enable the Email mapping button.

Project administrators may define detailed field mappings to more clearly define incident date.

64.2 Enabling Email Field Mapping

In ServiceWise, project members and employees may submit support incidents to work projects by sending structured email messages to a defined email address. ServiceWise automatically creates new support incidents based on the content of the subject line and body of the email.

To enable email field mapping:

1Add or edit an employee group in the Email Auto Submit tab of the Email 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 email incident submission group may submit incidents by email.

3Select the Support Email Field Mapping check box in the Employee Group to be Autosubmitted dialog box.

64.3 Customizing Email Field Mappings Tags

In ServiceWise, project members and employees may submit support incidents to work projects by sending structured email messages to a defined email address.

ServiceWise automatically creates new support incidents based on the content of the subject line and body of the email. Incident submission email messages may incident custom email submission tags that represent incident property variables.

All email submission tags may be customized. Project administrators may define field mappings between incident fields and email submission tags and the field delimiters that are used to identify those tags in the body of the email submission message.

Project administrators may map incident fields to customized email tags in the Email Field Mapping manager and define the field delimiters that are used to identify those tags in incident submission email messages.

To edit the name of custom email tags:

1Select the Email Mapping button.

The Email Field Mapping dialog box appears.

2Select an incident field in the Email Field Mapping list.

3Click the Edit button.

The ServiceWise Field dialog box appears.

4Define the name of the custom email tag in the Mapped Name text box.

5Click the OK button.

The ServiceWise Field dialog box closes.

To define custom email tag field delimiters:

1Select the Email Mapping button.

The Email 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 email incident submission supports four different characters as field delimiters for custom email tags:

• chevrons:

• braces: {FIELDNAME}

• brackets: [FIELDNAME]

• parentheses: (FIELDNAME)

5Click the OK button.

6The Define Field Delimiter for Auto Submit dialog box closes.

64.4 Managing Email–Incident Field Mapping

Project administrators may define the relationship between the incident properties defined in the email and the incident property fields managed in the ServiceWise database by defining email-mapping rules in the Email Field Mapping manager.

The Email 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 email.

Note:ServiceWise Email Auto Submission supports all system and custom-defined incident property fields.

Define mappings between the ServiceWise database and the email format. Employees can then use the email body (with proper formatting) to define multiple fields on the incident description and current status page.

To define email 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 email.

2Enable support for email field mapping.

3Select the Email mapping button.

The Email Field Mapping Manager appears.

The Email Field Mapping manager displays every incident property field used in the current project.

4Select a incident property field in the Email 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 Email Field Mapping list

64.5 Defining Email Field Mapping

To enable email field mapping:

64.6 Understanding Incident Email Submission Formats

To enable email field mapping:

65 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 email, or approval from management.

65.1 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.

65.2 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.

65.3 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 email, 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.

65.4 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.

email announcement event type:The email announcement event type defines a set of business rules for managing email blasts.

email received event type:The email received event type defines a set of business rules for managing email sent from an employee to a team email account.

email sent event type:The email received event type defines a set of business rules for managing email sent from a team email 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.

65.5 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

66 Defining General Event Settings

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.

66.1 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.

66.2 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.

67 Managing System Event Templates

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.

68 Managing Definable Event Templates

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 email, 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.

68.1 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 email 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

• email announcement event type

• email received event type

• email sent event type

• 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

• email announcement event type

• email received event type

• email 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”.

68.2 Deleting Event Templates

To delete an event template, select the event template in the Event Template list control and click the Delete button.

69 Administering General Event Template Properties

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.

email announcement event type:The email announcement event type defines a set of business rules for managing email blasts.

email received event type:The email received event type defines a set of business rules for managing email sent from an employee to a team email account.

email sent event type:The email received event type defines a set of business rules for managing email sent from a team email 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.

69.1 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.

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.

69.2 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.

69.3 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

69.4 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.

69.5 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.

70 Administering Global Event Templates

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

70.1 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.

70.2 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.

• 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.

70.3 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.

71 Administering Event Submission Access Controls

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

72 Administering Event Editing Access Controls

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.

72.1 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.

72.2 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.

73 Administering Event Attachment Rules

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.

73.1 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.

73.2 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.

74 Managing Regular 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

74.1 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 user-defined 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 regular event type option the Event Type dropdown list control.

5Click the OK button.

The Add a New Event Template dialog box closes.

74.2 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.

74.3 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.

74.4 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.

75 Managing Asset Operation Event Type 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 email 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, Email Announcement Event event type, Email Received Event event type, Email 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

75.1 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 user-defined 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.

75.2 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}

• {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.

75.3 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.

75.4 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.

75.5 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

76 Managing Autodiscovery Asset 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 email 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

• email announcement event type

• email received event type

• email sent event type

• 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

• email announcement event type

• email received event type

• email 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”.

76.1 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

76.2 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.

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 user-defined 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.

77 Managing Email Announcement Event Templates

To delete an event template, select the event template in the Event Template list control and click the Delete button.

77.1 Enabling Automatic Event Status Definition

Project administrators may enable the status of email announcement events to be automatically defined whenever an email is sent.

The Auto Set Status to when All Emails 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 email has been delivered.

The Auto Set Event Status To When All Emails Are Sent dropdown list is only displayed in the Properties page if the event template is defined as a email announcement event in the Event Type dropdown list.

The Email Announcement event type represents a set of business rules for managing email announcement events.

77.2 Creating Email Sent Announcement Templates

To create and define email 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 user-defined 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 email 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.

78 Managing Email Received Event Templates

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

78.1 Creating Email Received Event Templates

The Email Received event type represents a set of business rules for managing email received events.

An email received event based on an email received event template is created automatically in a ServiceWise project whenever an employee sends an email to the support team.

Project administrators may create multiple event templates based on the Email Received event type in the Event Templates page of the Event Management folder in the ServiceWise Admin client.

Email received event templates are crucial to ServiceWise project workflow and event tracking. Every email received by the ServiceWise email retrieval service is represented and tracked in the ServiceWise project as an event.

All email retrieval events are created from event template that are based on the Email Retrieval event type. A project administrator must define at least one email received event in every ServiceWise project for the ServiceWise email integration features to function properly.

Every administrator-defined team email address is assigned a default email received event template and a default email sent event template. Email sent to or sent from that email address automatically generate an event based on the corresponding event template.

Project administrators may multiple email received event templates only if they have enable advanced email settings in the project and defined a single team email address. For more information see See “Defining Team E-mail Accounts” .

79 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, email, and web conversations.

79.1 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

79.1.1 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 email addresses and define default settings for email 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.

80 Administering Employee View Customization

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

80.1 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.

80.2 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.

80.3 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 email 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.

80.4 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.

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.

80.5 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.

80.6 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 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.

80.7 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.

81 Administering Common Email Addresses

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 email addresses and define default settings for email 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.

82 Managing Employee Types

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.

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

82.1 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.

82.2 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 project-level 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.

82.2.1 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

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.

82.3 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

82.4 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.

Table 13-3: Employee Work Project-Specific Access Controls

82.5 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.

82.6 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.

83 Administering Employee Management Access Controls

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.

83.1 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.

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

83.2 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 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.

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

84 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 285.

84.1 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. 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

84.2 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.

84.3 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.

84.4 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.

84.5 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.

85 Defining General Employee Web Portal Settings

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. 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

85.1 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.

85.2 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.

85.3 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 project.

For a support project, employees may view, update, and submit support incidents and events.

85.4 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.

85.5 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,

http://WebServer/scripts/texcel/helpdesk/Clogin.dll?Projec-tID=1&RunTimeKey=USAMarket

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

85.6 System runtime keys The system runtime key

enables employees to access all TechExcel ServiceWise work projects.

http://WebServer/scripts/texcel/helpdesk/CLogin.dll?RunTime- 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.

85.7 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.

85.8 Work project runtime keys

Work project runtime keyswhen used in conjunction with project IDs may enable employees to directly access work project login pages.

85.9 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:

http://WebServer/scripts/texcel/SWise/Clogin.dll?Projec-tID=10

85.10 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.

85.11 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.

85.12 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.

85.13 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.

86 Managing Employee File Attachments

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.

86.1 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.

86.2 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.

86.3 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.

87 Managing Registration Controls

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.

87.1 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 (email 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.

87.2 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.

87.3 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.

87.4 Defining Registration Methods

Administrator-defined registration method rules determine whether employees may automatically access and work in the Employee Web Portal after they have self-registered or whether they are sent a password by email 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 Email First for Access Password registration method

87.5 Defining Web Portal Registration Email Notifications

To define Employee Web Portal registration email notifications:

1Select the Auto-send Email for Newly Registered Employee check box in the Email Notification page in the Registration Control subfolder of the Employee Web Portal folder in the ServiceWise Admin client

If this option is enabled an email is automatically send to the employee containing the user name and password. The email is sent regardless of the registration method selected by the administrator. For more information see See “Defining Registration Methods” on page 293.

2Define the title of the email notification in the Email Title text box control.

3Define the body of the email notification in the Email Message control.

4To restore the default email notification message, click the Default button. The default email notification message includes variables that represent the employees email address and password.

Based on registration data, we have created a login account to our Employee Web Portal.

Your login email address and password are listed below:

Login email: {Email Address}

Password: {Password}

Note that your password is case sensitive and your login name is your active email 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}

88 Managing Web Themes

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.

88.1 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:

Figure 14-9: Employee Web Portal Using Green Theme Web Theme

88.2 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.

88.3 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.

88.4 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.

88.5 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.

88.6 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.

88.7 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.

89 Managing Employee Web Portal Field Access Controls

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.

90 Managing Page Style Customization

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

90.1 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.

90.2 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.

90.3 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.

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

90.4 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.

90.5 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.

90.6 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.

90.7 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.

90.8 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.

90.9 Managing the Incident List Page

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.

91 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.

•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 email announcements may be sent to employees based the answers given to form questions. Project administrators may pre-schedule these email 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

91.1 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.

91.2 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.

91.3 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 email 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.

91.4 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:

http://www.yourdomain.com/FormWise 

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.

91.5 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.

91.6 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.

Table 15-1

92 Administering FormWise E-mail Autoreply

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.

92.1 Enabling E-mail Autoreply

To enable TechExcel ServiceWise to automatically send e-mail announcements to customers based on data collected in web forms, select the Enable E-mail Auto Reply check box in the Outgoing Mail Setup page of the Web Activity and FormWise folder.

92.2 Defining Server Information

To define the outgoing e-mail 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 e-mail address, enter the address and the user name of the addressee in the fields provided.

All replys to the ServiceWise generated e-mail notifications are automatically addressed to the e-mail address and the user name defined.

3If the e-mail server requires authentication, select the My E-mail Server Requires Authentication check box and define the account name and password in the fields provided.

93 Understanding the FormWise Information Schema

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.

93.1 Web Clicks Manager

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

94 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).

95 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.

 

95.1 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.

96 Administrating ServiceWise Web Support and System-Level Settings

 

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.

96.1 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:

 

http://[WebServerName]/scripts/texcel/servicewise/ 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:

 

http://[WebServerName]/scripts/texcel/servicewise/ 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.

 

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.

 

 

 

96.2 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.

 

96.3 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.

 

96.4 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">

 

 

96.5 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.

97 Managing ServiceWise Web System 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

 

 

97.1 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,

 

http://[servername]/scripts/texcel/Swise

 

97.2 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,

 

http://[servername]/scripts/texcel/Swise

 

97.3 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.

98 Managing Multiple Web Server Support

 

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:

 

http://[WebServerName]/scripts/texcel/servicewise/ 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:

 

http://[WebServerName]/scripts/texcel/servicewise/ 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.

 

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.

 

 

 

99 Managing Interproject Switching

 

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.

 

100 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:

100.1 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.

100.2 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:

Table 17-1: Asset Description Page Customizations

100.3 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.

100.4 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 data-entry 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.

100.5 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.

101 Managing Asset Template Subassets

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.

102 Managing Asset Template Breakdowns

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:

Table 17-1: Asset Description Page Customizations

103 Customizing the Description Page

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.

103.1 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.

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

103.2 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

103.3 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.

104 Customizing the Value Page

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 data-entry 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.

105 Customizing the Support Plan Page

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.

106 Managing Asset Custom Pages

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.

106.1 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.

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.

106.2 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.

106.3 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

106.3.1 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

106.3.2 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.

107 Managing Product Upgrade Rules in the Asset Inventory

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.

107.1 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.

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

107.2 Editing 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.

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

108 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 email 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.

108.1 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.

108.2 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 email 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 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 email 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

108.3 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 emails 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.

109 Managing Knowledge View Access Controls

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.

110 Managing Editing Tools

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 email 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 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 email 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

110.1 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)

110.2 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.

111 Managing Email Announcements

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 emails 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.

111.1 Defining Email Blast Announcement Settings

Project administrators may define basic email announcement settings including SMTP outgoing mail server settings, email reply names, and email reply addresses in the Email Announcement page of ServiceWise work projects.

Project administrators may define the name and email address of the sender of the email. All replies to the email are automatically directed to the administrator-defined reply address.

For example, announcement blast email messages may be sent to employees fromABC Software Newsat the addresssales@abcsoftware.com.

To define email blast announcement mail server:

1Enter a name in the Reply Name field of the Email Announcement page.

For example,ABC Software News

2Enter a name in the Reply Name field of the Email 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.

111.2 Defining Criteria for Redundant Email Announcements

Project administrators may define rules that ensure that employees to not receive multiple copies of the same email blast announcement with a set time period.

Depending on the email blast announcement rules defined by project members in the ServiceWise clients, employees may be schedule to receive email announcements based on several different triggers.

The Time Period (Days) control in the Email Announcement page enable administrators to ensure that the same email is not delivered during the time period assigned by the administrator.

111.3 Enabling and Defining Email Announcement Engine Settings

The Email Announcement Engine checks email announcement rules on regular, administrator-defined intervals and checks to see if a email announcement rules has been triggered.

The ServiceWise Email Announcement Engine is an optional feature that requires a separate purchase from TechExcel.

To define email announcement engine settings:

1Select the Enable Email Announcement Engine for Handling Scheduled Announcements check box. The email announcement engine must be enabled for project team member to send email blast announcements.

2Define the interval between email blasts in the Email Announcement Engine Interval Time (in Minutes) control. Project administrators may define interval settings for numbers between 1 and 30.

111.4 Defining Employee Subscription Options

Project administrators may enable project members to unsubscribe to future email announcements.

To define employee subscription options:

1Select the Enable Employees to Define Email Announcement Preference check box.

2Select an option from the Stop Email Method dropdown list.

Project members may use one of two methods to unsubscribe:

• The Via FormWise e-mail subscription forms option enables employees to employees subscribe and unsubscribe to your e-mail lists.

• The Via e-mail reply with keywords option enables employees to unsubscribe by replying to the e-mail 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 e-mail 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 e-mail with word 'REMOVE' in the subject.

5Define the Message

Specify the instructional message to be displayed in the e-mail. This message should instruct employees how to unsubscribe from the e-mail list and will be automatically included in mass e-mails sent to employees.

112 Defining Dynamic FAQs

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.

Table 18-1: Knowledge View Access Controls

112.1 Enabling and Defining Dynamic FAQ E-mail Server Settings

To define dynamic FAQ e-mail server settings:

1Select the Enable Dynamic FAQ Feature check box.

2Enter a name in the Reply Name field of the E-mail Announcement page.

For example,ABC Software News

3Enter a name in the Reply Name field of the E-mail 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.

113 Customizing the Knowledge View

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 email announcements and knowledge items using advanced HTML and text editing tools.

113.1 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.

113.2 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.

113.3 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.

114 Managing ServiceWise-RightAnswers Integration

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)

115 Backing up the Document Files

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.

116 Managing ServiceWise Autorecommendations

Email announcementsare predefined emails 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 Email Blast Knowledge Announcement privilege may create a knowledge announcement in the Knowledge view and blast the customized email to all employees with a single click.

Project administrators may use controls in the Email Announcements page of the Knowledge view folder to enable email announcement support and email announcement settings in TechExcel ServiceWise projects. Email announcement settings are defined on a work project by work project basis.

Project administrators may not define email announcements in base projects. Project administrators may configure email announcement properties using controls in the Email Announcement page of the Knowledge view folder.

Note:The TechExcel ServiceWise Email Server programs must be installed for this feature to work correctly. The email retrieval service must be installed to process incoming emails, and the email notification service must be installed to process outgoing emails.

Email announcement administrative tasks include:

• Defining Email Blast Announcement Settings

• Defining Criteria for Redundant Email Announcements

• Enabling and Defining Email Announcement Engine Settings

• Defining Employee Subscription Options

116.1 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.

116.2 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.

116.3 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.

• 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.

116.4 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.

116.5 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 e-mail.

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.

116.6 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 e-mail.

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.

116.7 Defining Search Engine Keyword Matching Points

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 e-mail.

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.

117 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.

117.1 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.

117.2 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.

118 Administering Service Agreement General Properties

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.

118.1 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.

118.2 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

119 Administering Support Schedules

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.

119.1 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.

119.2 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.

119.3 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.

The Support Schedule Settings dialog box closes.

119.4 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.

120 Administering Service Agreement Statuses

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

120.1 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.

120.2 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.

120.3 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.

120.4 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.

120.5 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.

120.6 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.

121 Administering Service Agreement Templates

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.

121.1 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.

121.2 Service agreement type

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.

122 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.

122.1 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.

123 Enabling General Time and Service Management Features

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.

123.1 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.

123.2 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.

123.3 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.

123.4 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 393.

123.5 Enabling Time Usage Recording

To enable time usage recording, select the Record Time Usage when Incident is Forwarded or Closed check box.

123.6 Displaying the Billable Check Box to Employees

To display the Billable check box to employees, select the Enable Time Tracking check box.

124 Administering Standard Professional Services Management

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

124.1 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.

124.2 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.

124.3 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.

124.4 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 389.

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.

124.5 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.

124.6 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.

124.7 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.

124.8 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

125 Administering Advanced Time and Service Management

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.

125.1 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.

125.2 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.

125.3 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.

125.4 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

126 Administering Service Templates

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.

126.1 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.

126.2 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.

126.3 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 389.

126.4 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.

126.5 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.

126.6 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.

126.7 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.

126.8 Managing Service Template Sales Definitions

Service templates may be used to calculate the price of support services and bill employees for those services.

126.9 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.

126.10 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.

126.11 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.

126.12 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.

126.13 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:

Table 20-2: Service Template Access Controls

127 Administering Service Template Work Codes

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.

127.1 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.

127.2 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

127.3 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 399.

127.4 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 399.

128 Administering Service Template Volume Pricing

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 393.

128.1 Enabling 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

129 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 email notification messages and notification methods (email, pager, and mobile phone)

• Customized subscription rules including mandatory and optional notification subscriptions.

129.1 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.

130 Administering the ServiceWise Mail Service

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.

130.1 Reloading Settings to ServiceWise Mail Service

The ServiceWise Email Notification Service must be stopped and restarted whenever a change is made to incident notification settings.

To reload email notification settings, click the Reload Email Service Setting button in the Incident Notifications page of the Advanced Settings folder.

130.2 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.

131 Administering Incident Notifications

The ServiceWise Mail Service enables support organizations to integrate ServiceWise workflow, incident notification, event scheduling, and incident escalation with the convenience of email.

All email, 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 Email Server communicates with the ServiceWise Database Server and email server to find and send email 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.

131.1 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 Email Notification check box in the Incident Notifications page of the Advanced Settings folder.

131.2 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:

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 414.

6Click 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(email, pager, or mobile phone) and anotification message.

• To define an email notification action, select the Notify By Sending Email 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 Email 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.

131.3 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.

131.4 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.

132 Administering Incident Escalations

The ServiceWise Email Notification Service must be stopped and restarted whenever a change is made to incident notification settings.

To reload email notification settings, click the Reload Email Service Setting button in the Incident Notifications page of the Advanced Settings folder.

132.1 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.

132.2 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.

132.3 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 (email, 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.

132.4 Subscribers

ServiceWise enables administrators to manage both push email and pull email 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.

132.5 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(email, 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 email notification action, select the Notify By Sending Email 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 email messages may be identified for the last notification sent by each method. Custom notification messages may be defined in the Define Email 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 Email Escalations page to rename, incident escalation rules.

132.6 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.

132.7 Administering Incident Escalation Actions

Incident escalation actions define the time period that must pass before notifications are sent, the method used to notify subscribers (email, 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.

132.8 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.

132.9 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:

Email Notification:Email notification actions notify subscribers by email 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 email message may be sent for every notification method.

132.10 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.

132.11 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 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 administrator-defined 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.

132.12 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.

133 Administering Incident Notification and Escalation Conditions

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.

134 Administering Incident Notification and Escalation Actions

In ServiceWise, incident notification is the process by which stakeholders are notified (by email, 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 (email, 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.

134.1 Notification methods

ServiceWise supports three notification methods for both incident notifications and incident escalations:

Email Notification:Email notification actions notify subscribers by email 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 email, pager,andmobile phone when that notification rule is triggered.

134.2 Defining Notification Action Email Addresses

ServiceWise enables project administrators to define incident notification rules that automatically notify many different subscribers of the status of ServiceWise incidents.

Incident notification email may be sent to project members, employee contacts, and administrator-defined email address lists.

The email addresses of incident notification subscribers are managed in different tools in ServiceWise applications.

• Project member email 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 email addresses for each notification rule. The email addresses on that list are notified automatically whenever the incident notification rule is triggered.

134.3 Defining Email Notification Actions

To define email notification actions:

1Select an email notification rule in the Notification Rule list of the Incident Notifications page.

2Select the Actions tab.

3Select the By Sending Email check box.

Project administrators must enable email notification.

4Select an option from the Email Format dropdown list.

Project administrators may select the email format used to send email notifications to (internal) project members.

The Email Format dropdown list displays all of the email formats defined in the Email Format manager. Project administrators may define new email formats by clicking the Setup button.

5Select an option from the Email Format for Employee dropdown list.

Project administrators may select the email format used to send email notifications to (external) employees.

The Email Format for Employee dropdown list displays all of the email formats defined in the Email Format manager. Project administrators may define new email formats by clicking the Setup button.

134.4 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 email 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 email message in the Mobile Phone dropdown list.

The option selected in the Email Format identifies the email message that is sent to rule subscribers when an incident is first escalated and for every subsequent notification prior to the final notification.

134.5 Defining Incident Email Notifications

Email notification actions send email notifications to project members and employees whenever an event notification rule is triggered.

Email notifications may also be sent to an administrator-defined list of email addresses and user-defined cc lists.

• The administrator may define a list of email addresses that receive all email notifications relevant to a specific incident notification rule.

• Individual project members may define a cc list of email 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 email 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 email 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 email message in the Email Format dropdown list.

4Select an email message in the Last Email Format dropdown list.

The Email Format and Last Email Format dropdown lists display all administrator-defined email messages.

• The option selected in the Email Format identifies the email 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 Email Format identifies the last email message that is sent to rule subscribers before the escalated incident is reassigned.

135 Administering Potential Recipients and Subscriptions

Incident notification is an optional ServiceWise feature that must be enabled on a project-by-project basis.

To enable incident notification select the Enable Email Notification check box in the Incident Notifications page of the Advanced Settings folder.

135.1 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.

135.2 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 email addresses. Email notifications are sent to all email 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.

135.3 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 Email 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 Email 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.

135.4 Defining User-Defined Email Address List

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 Email 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 Email 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.

136 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 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 email notification messages and notification methods (email, pager, and mobile phone)

• Customized subscription rules including mandatory and optional notification subscriptions.

136.1 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.

137 Administering Event Notifications

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.

137.1 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 Email Notification check box in the Event Notifications page of the Advanced Settings folder.

137.2 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(email, pager, or mobile phone) and anotification message.

• To define an email notification action, select the Notify By Sending Email 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 Email 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.

137.3 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 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.

138 Administering Event Escalations

In ServiceWise, event notification is the process by which stakeholders are notified (by email, 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 (email, 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.

138.1 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(email, 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 email notification action, select the Notify By Sending Email 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 Email 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 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 Email Escalations page to rename, event escalation rules.

138.2 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.

138.3 Administering Event Escalation Actions

Event escalation actions define the time period that must pass before notifications are sent, the method used to notify subscribers (email, 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:

Email Notification: Email notification actions notify subscribers by email 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 email 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.

138.4 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.

138.5 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}

139 Administering Event Notification and Escalation Conditions

Event notification is an optional ServiceWise feature that must be enabled on a project-by-project basis.

To enable event notification select the Enable Email Notification check box in the Event Notifications page of the Advanced Settings folder.

140 Administering Event Notification and Escalation Actions

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(email, pager, or mobile phone) and anotification message.

• To define an email notification action, select the Notify By Sending Email 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 Email 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.

140.1 Identifying Notification Action Email Addresses

ServiceWise enables project administrators to define event notification rules that automatically notify many different subscribers of the status of ServiceWise events.

Event notification email may be sent to project members, employee contacts, and administrator-defined email address lists.

The email addresses of event notification subscribers are managed in different tools in ServiceWise applications.

• Project member email 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 email addresses for each notification rule. The email addresses on that list are notified automatically whenever the event notification rule is triggered.

140.2 Defining Event Email Notifications

ServiceWise enables project administrators to define event notification rules that automatically notify many different subscribers of the status of ServiceWise events.

Event notification email may be sent to project members, employee contacts, and administrator-defined email address lists.

The email addresses of event notification subscribers are managed in different tools in ServiceWise applications.

• Project member email 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 email addresses for each notification rule. The email addresses on that list are notified automatically whenever the event notification rule is triggered.

141 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.

142 Feature Summary

Capture Outlook Emails

Incoming and outgoing Outlook emails 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 email with the appropriate customer record.

Automatic Record Matching

Emails sent and received are automatically matched with existing ServiceWise information based on matching email addresses. Support teams link new and existing emails with employees, requests, or support incidents while adding Outlook emails 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

Add or update ServiceWise employee information directly from Outlook at the same time you add an email, 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.

143 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

144 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 emails as events in the work project.

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 Emails as Events Tab

End users may save emails from Microsoft Outlook to TechExcel ServiceWise as an event. When users choose to save an email 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 ‘Email received’ or ‘Email 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.

145 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.

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 emails, 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

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 email 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 emails 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.

146 Using TechExcel Outlook Sync

146.1 Add an Outbound Email to ServiceWise

When sending an email, you may now choose to save the email to TechExcel ServiceWise and associate the email 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 Email to ServiceWisebutton (Shown in image below).

4. Confirm the Send Email 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 email 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 email event.

7. Choose theEvent templateandEvent statusused to track this email activity in TechExcel ServiceWise.

8. You will now see this Email event and message from within TechExcel ServiceWise.

Please Note: An email can only be saved to one event. Once saved, the ‘Save email to ServiceWise’ button will be disabled for that email.

146.2 Add a Sent or Received Email to ServiceWise

Emails 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 email you have received or sent within Microsoft Outlook .

2. Press theSave Email to ServiceWisebutton from the ServiceWise toolbar.

3. Complete the Save Event dialog. Again, you may use this dialog to associate the email with the correct customer, contact, incident, and ServiceWise event. You may also create new customer and contact information from this dialog.

Please Note: An email can only be saved to one event. Once saved, the ‘Save email to

ServiceWise’ button will be disabled for that email.

146.3 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.

146.3.1 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:

146.3.2 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.

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.

146.4 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.

147 APPENDIX: Installing TechExcel Outlook Sync

When sending an email, you may now choose to save the email to TechExcel ServiceWise and associate the email 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 Email to ServiceWisebutton (Shown in image below).

4. Confirm the Send Email 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 email 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 email event.

7. Choose theEvent templateandEvent statusused to track this email activity in TechExcel ServiceWise.

8. You will now see this Email event and message from within TechExcel ServiceWise.

Please Note: An email can only be saved to one event. Once saved, the ‘Save email to ServiceWise’ button will be disabled for that email.