BookmarkSubscribeRSS Feed
Michel_Shahan
SAS Employee

This article provides best practices for contacting SAS Technical Support in order to report issues or ask questions. Although you cannot always know what kind of information Technical Support will require to answer your questions and solve issues, your initial problem description should provide sufficient detail to be clear to the Technical Support Engineer that will perform the investigation. Note that some issues are complex and require time to analyze, and we might need more information.

 

Contact Methods

There are several ways to contact SAS Technical Support: web form, email, telephone, and chat. See Contact SAS Technical Support for details about each of these methods. SAS CI360 customers have another contact option that is built into the user interface—from the home page under Resource Center, select Contact Technical Support, as shown here:

 

Michel_Shahan_0-1675082290825.png

 

 

Clicking this link opens a client email that contains a partially prefilled template.

 

Essential Information

Regardless of which contact method you chose, each contact with SAS Technical Support about CI360 should include the following information:

  • What is your Technical Support site number?
  • What is the Tenant Moniker/Short Name (prefilled from CI360 link)?
  • What is the Tenant ID (prefilled from CI360 link)?
  • What is the Tenant Name?
  • On which environment is your tenant hosted (APN, EUW,MUM, SYD, or USE)?
  • What is the username (or name) of the person who reported the issue?
  • What is the phone number of the person who reported the issue?

In addition to that basic information, include a detailed problem description that includes the following to receive efficient assistance:

  • text that describes the issue with screen shots
  • the context in which the issue occurs
  • the extent of the issue
  • necessary attachments (logs or other files)

A broader context allows us to understand more about when and why the issue appeared so that we can try to find patterns. Logs and other files give us more detailed information about the issue. The type of logs and other files that are required can vary for different issues.

 

The list of questions below provides guidance about the type of information to include in your initial contact with Technical Support. These standard questions can help you write a thorough problem description:

  1. What is the issue?
  2. What type of object or function does it affect?
  3. What type of objects or functions does it not affect?
  4. What is the name of the object or function?
  5. When was the issue first seen? Be as specific as possible; for example, use 2:03 PM CET on 03JAN2023.
  6. Is the issue reproducible? If so, provide details about how to reproduce the issue.
  7. Does this affect a user (or multiple users)?
  8. Have there been any changes on your side that could explain the issue?
  9. What have you done to try to solve the issue?

 

Here are example responses to the standard questions:

  1. “We get an error when executing a task.”
  2. “This happens executing a specific task.”
  3. “It does not happen when executing other tasks or segment maps.”
  4. “The task name is ‘holiday offer’.”
  5. “The issue was first seen yesterday around 9:15 am CET.”
  6. “It happens each time we execute this task.”
  7. “This is happening to all users.”
  8. “The task was last modified three weeks ago and was executed without error.”
  9. “We created a similar task, which executes fine.”

 

You do not need to answer these questions in bullet points; you could incorporate them into the problem description as text. The questions help you understand the information that we need when writing your problem description. The list of questions is not exhaustive, but complete answers to them will help us understand the issue. Provide as many details as necessary to fully describe the issue.

Additionally, we will request information based on the characteristics of the issue and on what object the issue occurs. Here is a few common issues and the type of information that we might request.

 

On-Premises Issues

If it is a on-premises issue, you should also include the onprem.log file that covers the date and time on which the issue was seen. Also include the onprem.log if you use the dm.sh commands because the details and the result of those commands are stored in that log. Task and segment map executions that are marked to be executed “On-Premises” also have the execution logs in the onprem.log. Note that Direct Marketing is a hybrid solution, which means that the error could be in the cloud or on-premises. The onprem.log is a good starting point for the investigation, which is why it is always best to include it in your initial contact with Technical Support.

 

API Calls and Questions

If you are experiencing issues with APIs, we need to know how you are calling the API. Providing the exact API call and/or the logs of the API invocation is helpful. We do not support custom written code, which is why it is important to simplify the invocation of call. That allows us to isolate the issue to the API call itself without having to understanding long and complex programs.

 

Mobile SDK Issues

If you experience a Mobile SDK issue, then detailed information such as app name and application ID, SDK version, device ID, and the SDK internal log are all pieces of information that will be helpful. You can see more information about which logs can be enabled on your test device in Enable SDK Internal Logging for Android or Enable SDK Internal Logging for iOS.

Please also note the troubleshooting page for push notification, which recommends things to investigate if you encounter issues.

 

CI360 UI Performance Issues

If you experience CI360 user interface (UI) performance degradation, it is always a good idea to check the SAS CI 360 Status Page to see whether there are any known issues. When you report the issue, try to explain whether the issue is isolated to a specific page or object. Replicating the performance issue while collecting a HAR file will be helpful for us to see the response time. See Usage Note 60268 for how to collect the HAR file.

 

Publishing Related Issues

If you are having issues with publishing, then information about what you are trying to publish, and the name of the object is needed. Gather information about when the publish event started and whether it finished. Take a screen shot of any error messages that appear. Understanding the extent of the issue will be helpful so note whether the issue is isolated to a specific object or whether it is a broader issue with publishing.

 

Insight Reports Issues and Questions

For Insight report related issues, include the tab on which you see the issue along with the task name. Screen shots are very helpful here. Screen capture the report(s) with the discrepancy. Be sure that the screen shot includes the name of the task.

 

Read-Only Tenant Access for SAS Technical Support

SAS Technical Support can be granted read-only access to your tenant by your administrator to allow us to gather information directly from your tenant to save time. For instructions, see Manage Access to Your Tenant.

 

Summary

This article provided a few examples of issues that you might encounter in SAS CI360 to provide guidance about what information to include when contacting SAS Technical Support. If you are unsure about what to include for your issue, we will guide you through the process when working with you.  

 

How to improve email deliverability

SAS' Peter Ansbacher shows you how to use the dashboard in SAS Customer Intelligence 360 for better results.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 0 replies
  • 919 views
  • 1 like
  • 1 in conversation