EmberApplication Platform
Menu
Back to path
Draft complete10 minutes

Service Desk, Application Services, and IT Operations

Support and provider escalation

Move a request through Service Desk, application, platform, and provider teams without losing ownership or context.

The short answer

Use one support record, keep an internal owner, and escalate by boundary. A provider ticket extends the investigation to a supplier, but it does not transfer TDE's responsibility for user communication, application decisions, or closure.

01

Intake

Give the user one front door

A clear intake route prevents users from guessing which provider or engineering team owns a symptom. The Service Desk records impact and context, then Operations directs the work to the team able to inspect the likely boundary.

The Ember support route is a proposed operating model. Collected evidence supports Service Desk intake and IT Operations routing, but the complete standard still needs attributable IT Operations approval, Engineering concurrence, and ARB use.

  • Keep the original incident or request identifier across internal escalations.
  • Assign a current owner even while the cause is uncertain.
  • Use the applicable TDE priority and major-incident process for impact and communication.
Proposed Ember support routeThis sequence is useful training context, but it remains an APPROVAL NEEDED standard draft.
01Service DeskCapture the request, impact, requester context, and initial evidence.
02IT OperationsTriage, coordinate, communicate, and assign Application Services.
03EngineeringInvestigate supported-pattern or platform-level technical issues.
04ProviderInvestigate service behavior through the applicable support channel.
02

Decision point

Escalate when the boundary or authority changes

Application Services should escalate when the issue requires platform engineering skill, a change outside its authority, or inspection of the shared Ember pattern. Engineering or Operations can involve a provider when evidence points to provider behavior or provider-only telemetry and action.

Escalation is not abandonment. The internal owner continues to coordinate priorities, user communication, workarounds, recovery decisions, and evidence until the request is closed.

  • Application issue: application code, configuration, roles, data behavior, or an application-specific integration.
  • Platform issue: a supported pattern, shared configuration, delivery path, or platform capability affecting one or more applications.
  • Provider issue: service degradation, tenant behavior, quota, or provider-controlled action supported by evidence.
Escalation changes the investigator, not accountabilityThe team with the needed access investigates. The internal service owner still coordinates the outcome.
01Application teamOwns application behavior, releases, data, permissions, and application evidence.
02Platform EngineeringOwns supported patterns and platform-level technical escalation.
03IT OperationsOwns coordination and provider-ticket tracking in the proposed model.
04ProviderOwns provider-controlled service operation under its service relationship.
03

Escalation packet

Send evidence a provider can use

Provider support cannot act efficiently on 'the platform is broken.' Supply the tenant or project scope, service and region when applicable, timestamps with time zone, sanitized request identifiers, observed result, expected result, reproduction steps, impact, recent changes, and checks already performed.

Do not place passwords, secrets, tokens, private keys, or unnecessary personal or controlled data in a provider ticket. Follow approved secure-transfer methods if a provider requires sensitive diagnostic material.

  • Record the provider case identifier and the internal incident identifier in both systems.
  • Assign the person or team responsible for provider follow-up and status translation.
  • Verify service recovery from the user's perspective before closure.

The Ember lens

The draft Ember support standard proposes City Help Desk to Airport IT Operations, then Application Services, Engineering, or a provider as the issue requires. It also proposes IT Operations Service Desk ownership of provider-ticket tracking. The source explicitly marks this model INSUFFICIENT until approval and concurrence are captured, so it must not be presented as established policy.

Responsibility remains

Opening a provider case does not make the provider the business or application owner. TDE still decides user impact, workaround, risk, recovery, acceptance, and communication. A provider response time is governed by the actual plan or agreement, not by this lesson.

Apply it

Prepare a provider escalation

A production application is reachable, but requests to a managed backend capability time out. Two applications in the same provider tenant are affected. Provider status shows no public incident.

  1. 01State why the evidence justifies provider investigation without claiming a provider root cause.
  2. 02List the sanitized technical details and impact evidence to include in the case.
  3. 03Name the internal owner for coordination, user updates, and case tracking.
  4. 04Define how the team will verify recovery before closing the incident.

Check your understanding

Make the ideas usable

2 questions
01What changes when an Ember issue is escalated to a provider?
02How should the proposed Ember support route be described today?

Source trace

Reviewable by design

Content owner: Wesley Almeida
Last reviewed: 2026-08-18

  • Ember support and provider escalation standard draft05-projects/vibe-coding-platform/resources/standards/
  • Ember platform project status and guardrails05-projects/vibe-coding-platform/PROJECT.md
  • Ember platform foundations course05-projects/vibe-coding-platform/resources/learning/ember-learn-platform-foundations-course-2026-08-11.md