L2/L3 Application Support Engineer - Azure Integration Services

At Fujitsu, we've been driven to create a sustainable world through innovation since 1935. Today, we lead in digital transformation globally with our 130,000 employees across 50+ countries. We empower our diverse community to achieve greatness through career development and opportunities. Explore our internal positions and join us in shaping a brighter future. Thank you for being a part of Fujitsu. We look forward to growing together toward a brighter future.

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. Remove this section after transition acceptance.

• 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.

At Fujitsu, we are committed to an inclusive recruitment process that values the diverse backgrounds and experiences of all applicants. We believe that hiring people from a wide variety of backgrounds makes us stronger, not because it's the right thing to do, but because it allows us to draw on a wider range of perspectives and life experiences.