PRODUCT & TECHNICAL SUPPORT

Turn one clear report into a traceable next step.

Choose the issue type, provide the minimum useful evidence and submit one structured ticket. Product, licensing, technical and private security routes now converge in the same controlled intake instead of separate email links.

CHOOSE THE RIGHT ROUTE

One issue type, one useful first ticket.

PRODUCT OR LICENSING

Activation, entitlement or compatibility

Include product name, edition, installed version, number of production sites and the exact licensing or rollout decision you need.

Create the ticket →

BUG OR TECHNICAL ISSUE

Behavior that can be reproduced

Include the environment, steps, expected result, actual result and a short sanitized error excerpt. State whether it started after a change.

Create the ticket →

PRIVATE SECURITY REPORT

Potential vulnerability or exposure

Describe impact, affected product/version and safe reproduction details. Do not place exploit code, credentials or sensitive customer data in the form.

Create the ticket →

BEFORE YOU SEND

Four details that shorten diagnosis.

01

Identify the build

Product, edition, installed version and platform version.

02

State the sequence

The last action before the issue and whether a change preceded it.

03

Separate outcomes

One sentence for expected behavior and one for the observed result.

04

Sanitize evidence

Remove credentials, tokens, customer data and unnecessary full logs.

RIVANOX SUPPORT TICKET

Submit the request without opening an email client.

Use the message field to start with the issue type, then add product, edition, version, environment, expected result, actual result and urgency. If a secure transfer is required, request it first—do not attach secrets.

Security boundary: Never submit passwords, private keys, complete access tokens or confidential production data. By sending the form, you confirm that you have read the Privacy Policy.

A support request is not closed by a success message.

It moves through classification, reproduction or verification, resolution or scoping, and confirmation. A request is treated as resolved only when the relevant result can be checked in the affected environment or the remaining boundary is stated explicitly.