Skip to content

Get support

Use Request Support in the deployed managed application or the contact shown in its approved Marketplace listing. A source-code portal URL or internal channel is not an approved customer support route unless it appears there.

Managed support workflow showing customer impact classification and redacted evidence, Request Support in the Azure Managed Application, iVedha Opsflw triage and investigation, recovery communication, and customer validation.

Keep one support record from initial impact through customer-validated closure.

Submit through the managed application

  1. Open the managed application Overview.
  2. Select Request Support.
  3. Enter Your Email Address.
  4. Enter a concise Request Subject.
  5. In Request Description, state the impact, start time, affected users or services, exact symptom, and troubleshooting already completed.
  6. Review the form for credentials, personal data, and customer content.
  7. Submit the request and retain the resulting reference.

Classify the impact

Use the severity term defined in the approved Marketplace support agreement. If the agreement uses P1–P4, classify impact consistently:

Severity Customer impact example
P1 critical Production service unavailable, widespread data ingestion stopped, or active security impact with no workaround
P2 high Major production function degraded or a material group blocked with no acceptable workaround
P3 medium Limited degradation, non-critical function affected, or an acceptable workaround exists
P4 low Information request, documentation question, or planned change guidance

This table helps describe impact; it does not create a response-time commitment. Support hours, initial-response targets, escalation intervals, and service exclusions come from the approved offer or service agreement.

Include

  • managed application resource ID;
  • subscription and application resource group names when approved for sharing;
  • deployment region and plan;
  • problem start time and time zone;
  • exact user-visible symptom;
  • affected endpoint or operation without credentials;
  • whether one or all users and networks are affected;
  • last known successful time;
  • Azure deployment or correlation ID;
  • redacted error code and message;
  • diagnostic steps already completed;
  • business impact and required response time.

Use this subject pattern:

[P1-P4] <application name> - <region> - <short symptom>

Use this description structure:

Impact:
Started:
Last known good:
Affected users, sources, or endpoints:
Observed error:
Expected result:
Recent approved change:
Checks completed:
Correlation or deployment ID:
Safe attachment list:
Contact and time zone:

Do not include

  • passwords, one-time passwords, API keys, tokens, cookies, or headers;
  • private keys or complete certificate bundles;
  • unredacted ARM parameters or environment dumps;
  • customer documents, indexed records, or personal information;
  • credential-bearing Git remotes or internal automation endpoints.

If the issue is an Azure purchasing, subscription, policy, or platform-service problem rather than application behavior, use the Azure support path approved by your organization.

Escalation and communications

  • Use the ticket reference for updates; do not split one incident across unapproved channels.
  • State immediately when impact or scope increases.
  • Ask for an escalation through the support route when the response target in the approved agreement is missed.
  • Record maintenance, workaround, recovery, and closure decisions.
  • For a suspected credential or data exposure, use the approved security incident route rather than attaching sensitive evidence to a normal ticket.