RFS requirements

PrintPDF version

When a 2nd level supporter creates an RFS (Request for Support) at https://rfs.excitor.com, full details of the following are expected:

  • The currently installed DME Server version and SP (or build number), for instance "DME 3.5 SP6"
  • The OS the DME Server is installed on as Java, though multiplatform etc. do behave differently on different OS types
  • The DBMS used by the DME Server
  • The same details for the DME Connector (OS, installed where, connection type to DME Server)
  • If the issue involves a DME Client, then the full details of the client (device type, model, possible firmware) and the full DME Client version (3 digits)
  • If the "Category", "Sub category" and "Item" in the RFS creation form have valid entries for you problem, then select them.
  • And finally - a proper description of what you, 2nd level support, have done so far, so we know what has and has not been tried.

What happens if some of the above is missing?

We will keep newly created RFS in the "Qualifying" state until we have the details needed to understand the issue.

We do not start working on issues that we don't have the full details on, so please have them ready up front to speed up the process.

When time permits, we can assist you in gathering the missing details and are willing to provide you with hints/ABC-guides to get the information. Depending on the current load on the support team, an incomplete RFS will have to be prioritized down as we are not able to analyze further without all the required information. Please fill in as much context as possible whenever creating a RFS, too much information (even irrelevant) is better than missing information.

We don't have any discrepancies between an iPhone client that has a spelling mistake in the DME Client or a device that can't sync. We always prioritize "server down" very high and do what we can to get it up and running as fast as possible.

Usually, regardless of the problem, if it is not a known problem, we will request a STR (Steps To Reproduce). Especially for problems that haven't been reported before, which can be a bug or a scenario for a usage of DME that was not intended or fails for some reason in the customer environment. 

Clear STRs can also help us and yourself to identify if the problem could be related to documentation, meaning that the user is expecting a function or feature from DME that isn't there. One example could be questions related to iOS push notifications: why does DME need them when the native e-mail can sync in the background? The simple reason for that is that only Apple apps are allowed to run in the background, DME can't due to Apple limitations.