Skip to main content

IMPORTANT - Product End of Life Statement - IMPORTANT

Request RE, Survey, and Calendar 1.5 Support Ending December 31, 2020
Contact Kinetic Data Support with Questions
Kinetic Community

Organizing Your Service Portfolio


The following document outlines the process for defining requirements and best practices for organizing your service portfolio.   In this context the “Service Portfolio” refers to all services, whether planned, published, or deactivated.  “Catalog” refers to a grouping of service items for a specific purpose published to your customers. A catalog could be “IT Service Requests” or “HR Forms”.   Some or all of these forms could then show up on one or more web-based portals.   Portals often include items such as categorized service items & descriptions, searching, and the user’s request status’.


Early on a customer should decide how they want forms to be accessed.  The typical scenarios include:

Type Description Pros Cons

Existing Portal/Site

Links are published in various places on an existing website/portal

  • Site is already branded/established place for users to access information
  • No singular place for users to go and see request status
  • May be difficult to find resources to update existing portal

Embed Request Info in Existing Portal/Site

Links and request status are embedded in an existing site using an integration strategy.  Strategies include using an iFrame (virtual frame), or using the Java API to access request status from Kinetic Request.

  • Site is already branded/established place for users to access information
  • More flexible than the static links in the previous example.
  • May be difficult to find internal resources to update existing portal and/or write integration

Use Kinetic Request Portal Builder

One or more portal pages are created for a catalog, which typically list categories, service items, descriptions, searching and service request status.  Branding can be applied so the page(s) look/feel like other sites within the company.

  • Categorization, searching, and request status display built-in
  • Changes in forms categorization and request status instantly updated
  • May need to publish new portal address/URL to other sites, customers and employees
  • Will need to include branding/style (although minimized with good branding standards--See Delivery Model Branding document)


Document the catalog requirements.  These requirements can then be passed on to the portal and forms developers to create the pieces needed to publish portal.

Note:  The catalog requirements will likely including branding/style information.  This is often collected in the Delivery Model – Branding document.

Requirements For An Existing Portal

Requirement Notes

Page(s) to embed links


Text to use on links (Service Item Name, Description, Type, etc).


Process for updating links when service items added/removed


Integration Notes (if any)





Requirements For Kinetic Request Portal

On a typical portal, service items are segmented by category.  Service Items can be included in more than one category (Example:  Laptop Request may show up in Hardware and Top Five Service Items).   Start with a list of categories to assign service items to.  However, this list will likely change as the portal grows and service items are better defined later in the process.


Category Description (shown on portal) Icon/Image (if any)


Example:  The following service items relate to IT supported hardware requests. 

Found on sharepoint icon repository.




Top Five Services















Item Notes


Example:  Ellen Smith is the contact for the icons listed in the categories.


Example:  See branding doc for pages to mimic.  Header will be consistent with forms.  Left column will have current stock price (feed) and links to other top level pages from intranet.

Items per category

Example: We will show five service items per category with a drill down to show more.


Example:  Searching will take place on the catalog name and will search as you type.  Search box in top left







Available in most Kinetic Request portals is a table or list that allows for users to see requests, associated tasks, and the status of the requests.  By default, these are request items submitted from Kinetic Request. 

It is also possible to show additional information from other Remedy forms (eg. Incident or Change). This can be done using bridges and combining the data for a single display. This method can also display Incidents or Changes that weren't initiated by Kinetic Request.

Do note that requests may eventually create records in a number of applications (Incident, Change, Problem, Custom, etc.).  Because of this it is a good idea not to lock yourself into one specific model for this table.  Keeping the columns and data pulled as generic as possible, helps reduce maintenance as forms expand into many areas of your environment. 

Often the columns used are: Submission/Creation Date, Name, Status, ID. Then, if one user can request on behalf of another, submitter and/or requested for are often added.


This table uses the default Kinetic Request layout showing requests and their associated tasks.  Users can click on the top bar to show In Progress or Closed requests.  In addition approvals can also be shown in this table or could be broken out into another table or another portal page. 

Items shown in columns should be short (50 chars or less, typically).  Drill down items (the arrow) can be longer (255 chars, typically).  Longer fields (greater than 255) will slow down query times.


Example MY REQUESTS Table Specifications

Item Notes

Items to Show

Example:  Show the last 15 requests.  Show both requests and approvals.

Table Name

My Service Items

Column: ID

Example:  Use the Kinetic Request ID (KSR00000xxx)

Column: Name

Example: Use the service item name for this identifier

Column: Status

Example:  Use the “Validation Status” field found on the Kinetic Request forms.

Column: Notes

Example:  Use the requester name if this is an approval.  Otherwise blank.

Column: Date

Example:  Use the submitted date

Column: Task (Task)

Example:  Use the task name

Column: Last Update (Task)

Example:  Use the task Modified Date field

Column: Status (Task)

Example:  Use the Status field on the task form

Column: Notes (Task)

Example:  Use the notes field on the task form





Example List

Tables don't work well for responsive themes and sometimes they just don't fit the desired look for a theme, so a list is desired instead. Below is an example of an example of a sample catalog My Request Listing:


With activity details that look look like this:


The details are much the same, just the display is different. One of the benefits for a list view, though, is that you can more easily conditionally show/hide things in the list. Having a column that is empty half the time because it is often not used is undesirable, but with a list view, if an item isn't filled in, you can hide the label (if desired).

Example Portals

A number of options, including the default for the Air bundle, are shown on the demo site. Looking through these can give you a more complete vision of what can be accomplished. Included here are a couple of different examples completed for one company.


Previous (Branding)                                                                                                                             Next (Web Messages)