Using the Deployment Sequence
20 min
gather the following information before performing the deployment account information the name of the your company the name, phone number, and email address of the primary contact person for this account the preferred time zone to use when the application performs email actions the preferred date/time format this is the default displayed in reports, dashboards, and outbound email the preferred currency symbol standard hours of operation business hours define how response times (such as those in escalations) are calculated the customer types serviced by your company for information about the data you'll need, refer to organizing your customer information docid\ xawvdatu5bxpj6hy6sz30 define the workflow for incidents, from notification of an incident to its resolution for information about designing incident workflow, refer to planning for incidents docid\ xawvdatu5bxpj6hy6sz30 define the workflow for service requests placed by users for example, service requests may include it tickets, requests to book a conference room, or orders for supplies for information about planning service request workflows, refer to planning for service requests docid\ xawvdatu5bxpj6hy6sz30 define the workflow for changes, from the initiation of a change request to its implementation in a production environment for information about planning a change workflow, refer to planning for changes docid\ xawvdatu5bxpj6hy6sz30 step description information entering account information docid\ uag7awdkqfzkwghl zoji define the customer types serviced by your company adding customer information docid\ p0kvb2e8vcq 5mdxw0tc define the workflow for incidents, from notification of an incident to its resolution setting up incident management docid\ mzi2nu028g3aztrr1faom define the workflow for service requests placed by users these can include it requests, booking conference rooms, or ordering supplies to support a particular department configuring the service desk docid\ wfrpumqa15cu7goajy1ok define the workflow for changes, from the initiation of a change request to its implementation in a production environment setting up change enablement docid 4logjsa7ufxshfmasw5hj defining the self service portal docid\ xawvdatu5bxpj6hy6sz30 define the customer self service portal, where customers can use a web browser to log incidents, place service requests, access the company knowledge base and track the progress of service ticket items in configuring the self service portal docid\ d38247fbpztwcwamr8bsj structuring your service organization docid\ xawvdatu5bxpj6hy6sz30 define the service structure of your company this includes the service catalog offered by your company as well as the service level agreements internal tasks involve defining the steps needed to provide each service offering in the service catalog working with the service catalog docid\ p uihzc9kg7asbco6l8ai defining your user interfaces docid\ xawvdatu5bxpj6hy6sz30 assemble the default dashboards to be displayed on the user's home page upon logging in, identify search criteria, and identify quick actions to benefit your users determine the core business functions to be stored in business objects as well as grouping similar business objects so that they can share fields also, determine relationships to be created between business objects to enable information to be shared design the forms used in your application based on these business objects working with dashboards docid\ gxhud4tc pf2lghusckyi using quick actions docid\ qc7s yrfjjgp1ybk v 1sworking with business objects docid\ fc0gphjlgvagjroz0s9gdusing forms docid 5dd6rlsb123v5tlqc9wfnusing layouts docid\ fuvwvqr6w3d1sxqeogpyx defining your users and roles docid\ xawvdatu5bxpj6hy6sz30 roles determine the access a user has to the user interfaces, which include forms, dashboards, and controls organize your users by job task before adding them to your application creating a test application docid\ xawvdatu5bxpj6hy6sz30 design a test case to determine that your application settings are producing the desired results before deploying the application defining your account settings tasks that will help you define your account settings include determine your hours of operation, taking into account any remote locations that can access the application determine smtp settings for sending email and email listener settings (pop or imap) organize microsoft sql server reporting settings note any integrated or add on modules for your application note additional service settings, including those for messaging and licensing servers identify the email client settings required to send and receive notifications refer to entering account information docid\ uag7awdkqfzkwghl zoji organizing your customer information items to pursue when organizing your customer information include what type of customers are you supporting? are they internal customers or external customers? are you a managed service provider (msp) for another organization? what is their level of expertise when using technology such as a self service module or an automated call center? distribution of your customer base this helps define your hours of operation the customer structure as it pertains to the environment for example, knowledge of the customer service and it departments is vital in designing the application the service level agreements that are being provided should every customer receive the same experience? does it differ by department? by company? refer to adding customer information docid\ p0kvb2e8vcq 5mdxw0tc planning for incidents incidents are events that are either caused by or may cause an interruption in the quality of service incident management involves creating, monitoring, evaluating, and resolving incidents the main goals of incident management are to restore normal service quickly and to reduce the impact on business operations questions to ask when planning for incident management include how are incidents classified? do you offer multiple services that will require different structures? how will a customer contact the service desk to submit an incident? creating an incident through the self service portal? or by calling or emailing the service desk to report the incident? what existing knowledge bases and other resources used for research are in place at your company? do you plan on implementing any? what escalation stages and follow up workflows are in place at your company? do you have a formal set of service level agreements or do they need to be developed? what is the criteria for resolving and closing an incident? how is this information captured and added to your knowledge base? refer to setting up incident management docid\ mzi2nu028g3aztrr1faom planning for service requests service requests are for normal services that do not involve a failure of some kind they can include requests for disk space or adding a new user to the application questions to ask when planning for service requests include what items are available for request in your service catalog? who will process service requests? what is the criteria for fulfilling a service request? refer to configuring the service desk docid\ wfrpumqa15cu7goajy1ok planning for changes change enablement is the process of assessing any impact or potential risk a proposed change could have on your organization before it is introduced the goal of change enablement is to manage the process of change without creating incidents related to change questions to ask when planning to manage a change through its lifecycle include how will changes be categorized? how is a change request introduced and approved? what is the schedule and process for implementing a change? is there a staging area for testing a change before implementation in a production environment? if needed, how will a change be rolled back in the production environment? refer to setting up change enablement docid 4logjsa7ufxshfmasw5hj defining the self service portal enabling the self service portal involves planning out the accessibility of services from this module what levels of access to the self service portal should be available? should it vary by contracted support level or service level agreement? what application information should be available to users in the self service portal? can the user access and search your organization's knowledge base, faqs, or announcements through the self service portal? can the user create a support ticket through the self service portal? if so, how will it comply with any defined service level agreements? can the user create a service request through the self service portal? if so, what items are available in the service catalog? refer to configuring the self service portal docid\ d38247fbpztwcwamr8bsj structuring your service organization structuring your company's service organization lends itself to planning out the workflows processed within typical roles include service desk analysts and service desk managers questions to ask when mapping out your service organization include who will assign incidents or service requests to service desk personnel? will the ability to assign an incident and its associated tasks be owned solely by a service desk manager, or can a service desk analyst take ownership upon submission? what restrictions, if any, are there between departments? can a service desk manager for group a manage incidents or service requests for group b? refer to working with the service catalog docid\ p uihzc9kg7asbco6l8ai defining your user interfaces as you map out the roles and workflows required to process information to a successful resolution, these components often dictate the user interfaces required to monitor and capture information in the application refer to working with dashboards docid\ gxhud4tc pf2lghusckyi , using quick actions docid\ qc7s yrfjjgp1ybk v 1s , and using forms docid 5dd6rlsb123v5tlqc9wfn structuring business objects about structuring business objects docid\ xawvdatu5bxpj6hy6sz30outlining group business objects docid\ xawvdatu5bxpj6hy6sz30outlining business object relationships docid\ xawvdatu5bxpj6hy6sz30organizing fields docid\ xawvdatu5bxpj6hy6sz30assigning layouts docid\ xawvdatu5bxpj6hy6sz30 about structuring business objects determine the central business functions that your organization needs to track and manage in the demo database contains business objects and other database structure elements to help you plan an effective design for example, a technical support center needs to track customer incidents, and a service organization needs to track service orders business objects would then be required for incidents and service requests also, determine the categories of data supporting these central functions, such as name, address, urgency, and order number information list your organization's central business functions or components list your organization's supporting categories of information or basic business components refer to working with business objects docid\ fc0gphjlgvagjroz0s9gd outlining group business objects group similar business objects so that they can share fields a group lead contains the shared fields, and the remaining group members are similar business objects, functioning in their own capacities for example, address could be a business object group because several types of addresses exist and contain similar information address would be the group business object and member business objects could be address email, address home, address work, etc from the business objects listed, outline the business objects that would benefit from sharing fields as part of a group determine whether each group member functions as a lead (contains central information) or supporting business object (contains supporting information) during the development of the business objects, note the types of information that can be stored continue adding to your list of business objects and add new business objects as needed refer to creating a group business object docid\ prrpnuvje8dmzc oaqymn outlining business object relationships when a business object must include information from another business object, create a relationship between the business objects each relationship comprises a parent business object functions as the center of a relationship child business object assists a parent business object by supplying it with additional data when creating the forms that appear in , parent business object forms appear in the main user interface and child business object forms appear as tabs in the lower pane from the business objects and business object groups that you have created, outline the business objects that need to be part of a relationship to help determine the business objects to relate, think about which business objects should appear on the same layout (that is, which business objects should appear as tabs on the form of another business object) categorize each relationship and determine the following which business object is the parent? which business object is the child? what type of relationship is most appropriate contains, associates, or embedded? whether it is a one to one relationship (parent has only one child), a one to many relationship (parent has several children), or a many to many relationship (child record has a relationship with more than one parent record) refer to about business object relationships docid\ fc0gphjlgvagjroz0s9gd organizing fields for each business object, list the parcels of information to store within the business object when creating fields, define the field properties, including its format (text box, datetime box, checkbox, etc ), length, default value, and requirement in completing a form after adding the fields, you can define additional field properties, including whether it has validation options or is encrypted certain fields may need to use expressions for calculating a value or use a counter to automatically increment a tracking number contained within refer to working with fields docid 0j8v1vxsnconit0dpqmtn assigning layouts layouts comprise the forms, tabs, and lists that display a complete view of the parent record and its child records in the application after creating business objects, the administrator adds a default layout for the business object refer to using layouts docid\ fuvwvqr6w3d1sxqeogpyx customizing your system designing dashboards docid\ xawvdatu5bxpj6hy6sz30defining search criteria docid\ xawvdatu5bxpj6hy6sz30organizing quick actions docid\ xawvdatu5bxpj6hy6sz30customizing the loading page docid\ xawvdatu5bxpj6hy6sz30 designing dashboards dashboards are groupings of dashboard parts that appear on the main user interface in the application dashboard parts comprise elements such as a specialized list to the home page dashboard, a chart, etc you determine the scope of each dashboard personal, global, or role (these are assigned to roles and called default user interfaces) create the default set of dashboards as an administrator however, you can grant permission to create additional custom dashboards to other roles, such as service desk manager refer to working with dashboards docid\ gxhud4tc pf2lghusckyi defining search criteria define default searches that users can employ from the application searches employ object matching, which combine business objects and expressions create the default set of searches as an administrator however, you can grant permission to create additional custom searches for other roles refer to configuring search docid\ vrdz4pzba x3tzkhct483 organizing quick actions define automated actions to perform routine tasks in the application quick actions are business object based create the default set of quick actions as an administrator however, you can grant permission to create additional custom quick actions to other roles refer to using quick actions docid\ qc7s yrfjjgp1ybk v 1s customizing the loading page customize the text that users see when the application is loading define a new global constant called applicationdisplayname refer to defining the loading message docid tctro1i 3qpxmlxyma1b defining your users and roles the roles you create let you define different views of the user interfaces you create later in deciding on roles to add, consider your users, and anticipate the job tasks they will perform upon logging in each role is likely to require a different set of forms, dashboards and controls to facilitate their job duties for example, a user in the self service portal who is interested in tracking a particular service request ticket would create the request using a form, while a service desk analyst would use a dashboard or user interface to process multiple requests from different origins a change manager is likely to require a different set of forms than a service desk manager, despite operating at a supervisory level list the types of roles that your organization needs group users within these roles creating a test application before implementing a production application, recommends testing your deployment design in an offline database
