Skip to main content

How to Submit a Bug to Arc Customer Support

You can open a ticket Arc Customer Support here

We’ve made some changes to our “Report a Bug” form — it has a few more fields so we can gather more specific information. We don’t want you to spend your whole day filling out forms, really, but the more details we can collect up front, the quicker we can get to resolving your issue.

Under no circumstances should you include or attach your reader/subscriber account numbers, mailing addresses, or other personally identifying information (PII) to this form. Sharing sensitive information through this form may violate the Arc XP terms of service. Nor should you ever include passwords, credentials authentication token values, etc.

Seriously, we want as much information as you can give us. Just not this.

Priority

P0 - Critical: Full outage or critical state in Production. This is a catastrophic event, highly visible to all or most of your audience. You need immediate help and an immediate fix.

P1 - High: Partial outage or degraded performance on Production. Something is very wrong, visible to much of your audience or has a large impact on your business. This can’t wait and must to be addressed now.

Note

P0 and P1 issues trigger our internal alerting process 24/7, ensuring immediate attention. Assign these priorities only when an urgent response is essential.

The priorities below are still very important to us. If we receive this after hours, we promise we’ll contact you first thing in the (business day) morning and get our engineering teams working on it.

P2 - Normal: Performance issue or bug that does not significantly disrupt use of the site/software, but it impacts your operations or workflow.

P3 - Minor: Minor error/defect not visible to most or has a low impact on your business.

P4 - Low: Platform feature or enhancement requests, issues where Arc products can better align with your business needs.

See your organization’s SaaS Agreement for a full description of the priority definitions.

Summary

This is the “short version” of the issue. Think of this as the issue’s Title. Keep this concise and informative.

Example 1:

Newly published articles in the sports section not appearing on web site

Example 2:

Photo Center returning “Unable to save” error when saving a gallery

Example 3:

Users in the Editors squad are unable to access Composer tile in Sandbox

Background

This is the “narrative version” of the issue. Tell us your own words what’s going on, providing any history or context that will help us understand. Explain why you feel the issue is caused by the Arc platform, and outline any local debugging that led you to this conclusion. Include any information which will expedite debugging (error messages, story ids/links, PB page/template/feature names, environment affected, etc.). However, use the fields below to provide Expected Results, Actual Results, and Steps to Reproduce - without this information, the Support Engineers cannot even begin an investigation.

Examples are crucial. We believe you that something may be amiss, but without supporting information, it can be difficult - if not impossible - to start an investigation. We’re not trying to make you prove something is broken, we just need a concrete place to go so we can see what you’re seeing. Things that are obvious to you may not be obvious to us. Keep in mind that Arc is a very flexible platform and is used in different ways by every organization. Although our support team are experts in using the Arc platform, we likely don’t understand the nuances of your particular workflow.

Think of answers to questions that would help us investigate the issue:

  • Timing: When did this start happening?

  • Frequency: Is it consistently happening, and if not, do you see any particular pattern in when it happens?

  • Platform Scope: Does it only happen with a single item (story, page, site, section, etc.) or user?

  • User scope: Does it affect your audience and/or internal Arc users?

  • Impact: What is the impact of this issue on your organization or your readers?

And we love visuals. Screen shots or, better yet, screen recordings help us see exactly what you’re seeing. Other information such as output from a browser’s developer tools, or a .HAR file can tell us what may be happening under the hood. We may ask you for these things, but if you think it may help expedite the investigation - don’t wait to be asked.

While we love screen shots, this is not a substitute for providing a link or document ID. We’re pretty good at guessing, but asking us to identify a 26-character alphanumeric string from a photo of a monitor leaves it open to speculation, interpretation and human error. Not to mention poor eyesight. Provide text that can be easily and reliably copied and pasted for best results.

Example 1:

Our newsroom published this story earlier today, and it should have appeared on the web at Pretend-Site.Com/Myarticle. It’s been two hours and it still is showing a 404 on the live site. The Website URL looks correct, and matches what we expect to see. Story: Https://Pretend-Site.Arcpublishing.Com/Composer/Edit/U6XBXAOWQ5FUDRRG37FOBXG2EM/ Attached is a screen shot showing the article with the Published status and the Website URL. Https://Www.Pretend-Site.Com/News/Article-123

Example 2:

Our photo editor annie.leibovitz is trying to add photos to an existing gallery, Pretendsite.Arcpublishing.Com/Photo/Gallery/EMAKJNA6JNE4NCKW7I4LR1LZYQ. She can edit the gallery and select new photos, but when she presses Save, she receives the error (see screen shot). She says she’s edited the gallery in the past, as recently as yesterday, this is the first time she’s ever run across this error. Her permissions seem fine to. Can you help us figure out what’s going on?

Example 3:

In Sandbox, I created a squad called “Editors” and assigned it to the Default role, which has all of the Composers permissions selected. Yet my test user “Test123” can’t see the Composer tile at all, so they can’t even get into Composer. What am I doing wrong? Here’s a screen shot of the squad’s setup at Sandbox.Pretend-Site.Arcpublishing.Com/Permissions/Admin/ and you can see the role setup at Sandbox.Pretend-Site.Arcpublishing.Com/Permissions/Admin/Roles/Default I’ve also attached the JSON results of user Test123′s permissions from Sandbox.Pretend-Site.Arcpublishing.Com/User

Expected Results

What were you expecting to see? Be as specific as possible (what symptoms are visible to readers/newsroom, expected behaviors) about the symptoms you are seeing.

Example 1:

This story was published 10 minutes ago at 4:05 p.m. Based on my understanding of cache clearing, this story should have been visible in in a few seconds.

Example 2:

Given her permissions, jane.doe can add photos to an existing gallery. (She’s done this in the past)

Example 3:

As a member of the Editors squad, user Test123 would be able to access Composer

Actual Results

What did you actually see that you weren’t expecting?

Example 1:

example-site.com/myarticle returns a 404

Example 2:

Starting today, Jane receives a “Unable to save” error when adding photos to an existing gallery. (link to gallery above)

Example 3:

User Test123 can’t see the Composer tile

Steps to Reproduce

Submitting a ticket with insufficient Steps to Reproduce or comments such as “see above” or “n/a” will result in an immediate request for additional information and will delay any investigation. Detail steps in this field.

Since we aren’t looking over your shoulder, we can’t see which field you were in, how you got there (did you click, or did you tab?), and what you did when you got there (did you begin typing text, or did you copy a manuscript from another source?).

Clearly some issues need more detailed steps than others. But if a user is having trouble logging in, for example, it makes a difference what URL got them to the point they’re at - perhaps it’s an outdated bookmark that we can’t see. With explicit steps, we can recreate the situation and “follow along” with the user. And once again, while screen shots and recordings are very helpful, they can’t always tell the whole story.

Sometimes there are multiple ways to achieve the same result in the Arc ecosystem; it’s important that we know exactly how got to the point you did.

Example 1:

  1. User created story directly in Composer (making many revisions). User received no errors while editing the story.

  2. User clicked the Publish button at the top of the story in Composer.

  3. Story shows “Last Published: Jun 31, 2020 4:05 PM” and the corrected expected Website URL.

  4. In spite of all this, URL on website is 404ing.

Example 2:

  1. Log in to Arc XP (example.arcpublishing.com)

  2. Select Photo Center

  3. Click on “Galleries”

  4. Edit the gallery by clicking on the gallery name, “Photos of the World”

  5. Click “Upload Images”

  6. Click “Select Files”

  7. Select “bigspreadsheet.xlsx” and “largerspreadsheet.xlsx” and press “upload”

  8. Error banner appears at bottom of screen (see screen shot).

Example 3:

  1. Log in to sandbox.example.arcpublishing.com as user Test123

  2. Composer tile is not present. (But other tiles are.)