L2/L3 Application Support Engineer - Azure Integration Services

Fujitsu Philippines Inc.; Manila; On-site; PHP 700,000 - 900,000; Full time

Job summary

Fujitsu Philippines Inc. seeks an experienced L2/L3 Azure integration support engineer to provide second- and third-level support for near-real-time customer integration platforms built on Azure services including Service Bus, App Services and API Management.

You will perform shift health checks, triage issues, recover components and build proactive alerting, escalating code-level defects to L3 teams. You will also design, implement, and tune monitoring, dashboards and alerts, support

Qualifications

• Demonstrated production support of Azure integration services: Service Bus (topics, subscriptions, dead-letter queues), App Services and Function Apps, API Management.
• Application Insights, Log Analytics and KQL for diagnosis, plus Azure Monitor alerting and dashboards.
• ITIL-aligned incident, problem and change practice using ServiceNow or equivalent. Shift handoff discipline.
• Clear, compliance-aware incident communication with business and technical stakeholders.

Responsibilities

• Own incidents for the customer integration platform through resolution or hand-off.
• Triage runbook failures including dead-letter queues, data errors and MDM issues.
• Distinguish platform faults from source-data or downstream faults and route accordingly.
• Restart App Services and Function Apps with authorization when needed.
• Perform controlled replay or disposal of dead-lettered messages.
• Design and tune Azure Monitor alerts, dashboards and baselines.
• Support deployments by validating components during releases.
• Investigate data errors against MDM/Salesforce/JDE/AMCS/NAV.
• Raise problems and maintain runbooks and knowledge articles.

Skills

Service Bus topics subscriptions DLQ

App Services and Function Apps

API Management

Application Insights / Log Analytics /

Tools

Azure Logic Apps

Key Vault

Azure DevOps

ARM/Bicep deployments

Job description

1. Position purpose

Provide second-level operational support for Cleanaway's near-real-time customer integration platform, and second- and third-level support for other Azure integrations. The customer integration platform is built on Azure Service Bus, App Services, Function Apps, API Management and Application Insights. It synchronises customer data across Salesforce, the Master Data Management (MDM) platform, JDE, AMCS and NAV. The engineer performs shift health checks, triages dead-letters and data errors, recovers components, and builds proactive alerting, escalating code-level defects to the L3 application teams.

2. Key accountabilities

Incident management and service restoration

• Own assigned ServiceNow incidents for the customer integration platform through resolution or controlled hand-off to L3, with clear evidence and reproducible steps.
• Triage runbook failure modes, including dead-letters, data errors, master-ID integrity issues, receiver failures, silent stalls, MDM outages or disabled components, and authentication failures.
• Tell platform faults apart from source-data and downstream-system faults, and route each to the correct team.
• Restart stopped or failed App Services and Function Apps under the runbook, and seek L3 authorisation before intervening on components that are running but idle.
• Perform controlled replay, resubmission or disposal of dead-lettered messages under documented procedures, informing business owners.

Monitoring and operational health

• Perform the documented health check every shift: Service Bus active and dead-letter counts, App Insights failures and exceptions (KQL), component status and throughput against baselines. Record a handoff.
• Detect backlogs and silent stalls early. Escalate in line with priority and the agreed L2/L3 responsibility matrix.
• Design, build and tune Azure Monitor alert rules, dashboards and baselines for the platform, so that detection does not depend only on manual checks.
• Support deployments by stopping, starting and validating components during releases.

Integration and data support

• Investigate customer data errors against the MDM customer hierarchy (customer, billing account, site, contact) and the inbound and outbound directions between Salesforce, MDM, JDE, AMCS and NAV.
• Trace end-to-end transactions using Application Insights correlation and structured .NET logs. Diagnose APIM HTTP errors.
• Work with the MDM team, Salesforce support and ERP application teams to correct source data and confirm recovery.

Other Azure integrations

• Provide L2/L3 support for other event-driven and API-based Azure integrations (Logic Apps, Function Apps): monitoring, incident resolution, connector and credential maintenance, and minor enhancements through Azure DevOps and change control.
• Maintain certificates, secrets and connector authorisations for these integrations, and renew them before expiry.

Problem management and knowledge

• Raise problem records for recurring failure patterns such as silent stalls and data-error categories, and track permanent fixes with L3.
• Maintain the runbook, KQL query library, handoff log, alert catalogue and knowledge articles. Retire superseded wiki content.
• Create and maintain Azure DevOps work items for defects and improvements handed to L3.
• Participate in knowledge transfer from the incumbent provider, demonstrate independent handling of common support scenarios, and transfer knowledge to new team members.

Security and compliance

• Use privileged and production access only through the approved access process (e.g. CyberArk), on a least-privilege basis and for authorised tasks.
• Never record passwords, tokens or other secrets in tickets, email or documents. Store and hand over credentials only through the approved vault.
• Handle customer, employee and payroll personal information in line with the Privacy Act and Cleanaway data classification, including compliant incident records and escalation of potential data breaches.
• Maintain segregation of duties: perform data corrections, approvals and production changes only with documented business or change approval, and keep an audit trail.

3. Role boundaries

L2/L3 accountability

• Own shift health checks, monitoring, incident triage, documented recovery, alert build-out and escalation packages for the customer integration platform.
• Own L2/L3 support for other event-driven and API-based Azure integrations in scope. Function Apps and Logic Apps that run as steps within batch data pipelines belong to the ADF/Databricks engineer.
• Retain ServiceNow ownership and stakeholder communication while L3 performs code-level remediation.

Outside delegated authority

• Code changes to the customer integration platform's App Services and Function Apps, which belong to the L3 application teams unless formally transferred.
• Platform architecture, Service Bus topology and APIM policy design.
• Business decisions on customer master data, matching and survivorship rules owned by MDM and business data owners.

4. Skills and experience

Essential

• Demonstrated production support of Azure integration services: Service Bus (topics, subscriptions, dead-letter queues), App Services and Function Apps, API Management.
• Application Insights, Log Analytics and KQL for diagnosis, plus Azure Monitor alerting and dashboards.
• Ability to read structured .NET application logs and trace distributed transactions.
• ITIL-aligned incident, problem and change practice using ServiceNow or equivalent. Shift handoff discipline.
• Clear, compliance-aware incident communication with business and technical stakeholders.

Desirable

• Salesforce, MDM (e.g. Ataccama), JD Edwards or AMCS integration experience.
• Azure Logic Apps, Key Vault, Azure DevOps and ARM/Bicep deployments.
• Experience raising and managing Microsoft Azure support cases.
• AZ-900, AZ-104, AZ-204, ITIL 4 Foundation, SC-900.

5. Key relationships

L3 application teams (customer integration platform): Code-level defects, running-but-idle interventions, releases and responsibility matrix

MDM team, Salesforce support and ERP application teams: Source-data correction and cross-system recovery

Cleanaway Integration L2 lead: Priorities, escalation, on-call model and readiness sign-off

Service Desk / L1: Intake, initial triage, shift-left knowledge articles and incident escalation

Technical Platform Owner / Principal Analyst: Platform priorities, risks, technical governance and acceptance

Change and release management: CAB approval, controlled releases and production validation

Infrastructure, DBA and Cyber Security teams: Servers, databases, privileged access, certificates and security approvals

6. Performance measures

• Incident response and resolution against agreed service levels and business-critical processing windows.
• Completion and effectiveness of proactive monitoring, exception detection and recovery.
• Service request timeliness and first-time-right fulfilment.
• Changes delivered successfully through change control, without unplanned outage or rollback.
• Reduction in repeat incidents through problem records, root cause analysis and permanent fixes.
• Accuracy and currency of runbooks, knowledge articles, ServiceNow resolution notes and operational documentation.
• Stakeholder satisfaction and timely communication during incidents and changes.
• Every shift health check completed and handoff recorded. No undetected backlogs or stalls.
• Alert rules and baselines implemented and maintained for the platform.

7. Transition readiness (by 21 December 2026)

Independence criteria Fujitsu must demonstrate before taking over from the incumbent provider.

• Before taking independent on-call, demonstrate core Azure BAU activities unaided: check App Service and Function App health and restart them; review and action Azure Monitor alerts; query Application Insights and Log Analytics with KQL; inspect, replay or dispose of Service Bus dead-letter messages; diagnose API Management HTTP errors; and interpret structured .NET application logs.
• Extend independent on-call progressively from single applications to multi-service and enterprise integrations. Each step requires demonstrated cross-system triage, Microsoft Azure support escalation, disaster-recovery procedures and compliance-aware incident communication.
• Shift health check and handoff performed without incumbent assistance.
• Dead-letter and data-error triage scenarios (including silent-stall and MDM-outage discrimination) handled unaided.
• L2/L3 responsibility matrix agreed with the L3 application teams. Alert rules and baselines in place.
• Incident SLAs met for four consecutive weeks.

8. Working arrangements and cross-cover

Provide coverage of Australian business hours (AEST/AEDT) through agreed shift patterns, including the Australian morning window. Participate in a rostered on-call arrangement outside business hours, including weekends, for incidents and business-critical processing windows, and in planned after-hours changes and maintenance. All operational activities must follow approved procedures, access controls, Cleanaway change governance and delegated authority. The platform has no out-of-hours self-healing. A per-shift health check is mandatory, and an on-call engineer signed off for independent on-call must be available for customer-sync incidents outside business hours. Until on-call readiness is signed off, the engineer works in paired mode.

Cross-cover: Secondary cover with the Informatica IDMC & OMS engineers for shared integration triage. A minimum of two engineers signed off for independent on-call is needed to sustain shift and on-call coverage.