Skip to content
  • There are no suggestions because the search field is empty.

Resources FAQ

This article applies to Pro, Team, and Legacy editions.

Table of Contents

 

How Do I View the Download Log for Files in Content or Releases?

Download logs show details on successful, failed, and abandoned file downloads for locally uploaded files.

Community content:

Animated screenshot showing how to access the download log for community content

1. Click the Community logo in the navigation bar.

2. Click Community administration > Content.

3. Hover over the desired content and click the wrench icon.

4. Hover over the desired attached file and click the clock icon.

Project content or release:

Animated screenshot showing how to access the download log for project content or releases

1. Click Management in the navigation bar.

2. Click Content or Releases.

3. Hover over the desired item and click the magnifying glass icon.

4. Hover over the desired attached file and click the clock icon.

 

Why Am I Being Told I'm Over the 60k Character Limit?

Centercode resources and email templates have a 60k character limit that includes background formatting data, not just visible text. Copy/pasting from an external text or document editor often brings along a large amount of hidden formatting. If your content appears to be under 60k characters, click the Source button in the visual editor to inspect and remove any extra formatting data.

Screenshot showing the Source button in the Centercode visual editor

 

Why Can't Participants See the Images in My Resource?

If participants can't see images that you can see, the images were most likely copy/pasted from another area of Centercode. Copy/pasted images retain the original view permissions from where they were copied, meaning only users in that original project can see them. The fix is to remove the pasted images and re-upload them directly to the new resource.

 

Should I use Content or Releases?

Content and Releases are both resources, and day to day you manage them the same way. You create them, set resource types, control access and visibility, track engagement, send notifications, and clone or archive them with the same tools. Four things separate them.

Scope

Content can live at the Community level as well as inside a Project, so it suits information you want to organize or reuse across more than one Project. Releases are managed inside a Project, which suits material tied to that Project's testing.

Version tracking

Releases carry a Version field, which Content does not. It tracks iterations of a resource so participants can tell which one is current. If you're publishing successive builds, that field is the reason to choose Releases.

Automation and integrations

Release types can be connected to the systems that produce your builds. Content types can't. If your builds come out of a pipeline or an app store rather than being uploaded by hand, this is the difference that decides it.

  • Release API: point your build or deployment tool at a release type's endpoint URL and send it a JSON payload. Centercode creates the release for you, with the title, body, release value, availability dates, and files attached from a connected Centercode FTP or linked from external storage. This needs Enhanced Integrations, a Community-level API key, and Team or Legacy edition. See the Guide to implementing release automation API.
  • App store automation: map a Centercode team to a TestFlight external testing group or a Google Play closed testing track. Centercode keeps that group's membership in sync with your team, watches for new builds, and creates a matching Centercode release when one appears, either as a draft you publish or fully automatically. See the Guide to App Testing via Centercode.

Release types carry the settings that make this work cleanly, including Single active release, which archives the rest of the type as each new build lands, Single notice, and Default team access for everything the integration creates.

What each one can do that the other can't

A few capabilities sit on one side only. Releases can be added to a feedback form as a Release element, so participants tag the build their ticket applies to and you can filter and report on feedback by version. Content has no equivalent. Going the other way, three notice types apply to Content only: digital agreement, block, and account verification. If you need participants to sign something or verify their account details before they can continue, that's Content.

A rule of thumb
  • Use Content for evergreen material: participant guides, onboarding instructions, reference information, anything you want to keep or reuse.
  • Use Releases for a specific build, version, or update you're putting in front of participants, along with its release notes and known issues.
  • Use Releases if your builds are produced by a CI/CD pipeline, TestFlight, or Google Play, since that's the only side you can automate.

Neither choice locks you in. Because both are resources, you can copy them between Projects either way.

Notes