Harborline Industrial Services: company and installed estate

The company

Harborline services pumps, compressors, and packaging machinery for manufacturers and distribution centers. It has 620 employees, eight regional branches, 190 field technicians, and approximately 1,400 active business customers. Customers purchase annual service plans, emergency repairs, and scheduled maintenance. Revenue is an illustrative $145 million per year.

The company processes 600 service requests each week. Most follow an ordinary dispatch path; approximately 160 require coordination across a customer commitment, a part reservation, technician qualifications, and access to a customer site. That difficult subset is the focus of this case.

Sales owns the relationship, service operations owns execution, procurement owns sourcing, and finance owns billing. Branch coordinators currently reconcile conflicting status through email, chat, calls, and spreadsheets. A person can promise a visit before the part or appropriately qualified technician is actually available. The customer hears a confident date while internal systems contain several conditional dates.

Business objective: reduce avoidable failed service commitments without reducing the business's ability to respond to emergencies. A failed commitment means an accepted service visit cannot begin in its agreed arrival window because Harborline did not resolve a known prerequisite. Customer cancellations and weather closures are recorded separately.

People and decision rights

Person / role	Accountability	Decision boundary
Maya Chen, COO and sponsor	Customer outcomes and investment	Approves funding and expansion; cannot waive a technical release defect alone
Luis Ortega, director of service operations	Business process and product ownership	Owns commitment policy, prioritization, and business acceptance
Priya Shah, regional coordinator	Workflow expertise and pilot feedback	Validates usability and realistic exceptions; does not approve her own restricted override
Jordan Bell, enterprise architect	System boundaries and solution choice	Owns architecture review and recorded alternatives
Nia Brooks, ERP owner	Inventory, reservations, and financial records	Approves ERP interface use and reservation semantics
Ethan Ross, field-service owner	Work orders, skills, and scheduling	Owns dispatch integration and conflict resolution
Sofia Malik, security lead	Identity, access, and security findings	Can hold release for unmet security criteria
Owen Reed, engineering manager	Team, capacity, implementation	Commits delivery scope within approved capacity
Amina Patel, QA lead	Verification evidence	Reports pass/fail independently of desired release date
Grace Kim, service owner / SRE	Reliability, release readiness, support	Owns incident response, rollback, and recovery acceptance
Daniel Price, finance partner	Cost assumptions and benefit validation	Confirms the forecast basis; distinguishes savings from released staff time

The investment gate requires Maya and Daniel. The architecture gate requires Jordan and affected system owners. The release gate requires Luis for business acceptance, Amina for evidence, Sofia for security, and Grace for operations. A missing required approval means no promotion; exceptions require a named accountable owner, scope, compensating control, and expiry.

Enterprise platforms and critical business software

These are assumed deployed products and locally supported interfaces in the fictional company. A real assessment must confirm the exact tenant, edition, API entitlement, service limits, contract, and configuration before relying on any interface.

ID	Platform / application	Critical business function and authoritative records	Owner	Assumed interface / constraint	Candidate role in this initiative
P01	Salesforce CRM	Accounts, contacts, sales opportunities, service entitlement references	Sales operations	Approved account export/API; operational users have limited CRM access	Existing-module candidate; retain customer/account authority
P02	Dynamics 365 Business Central	Parts, purchase orders, inventory reservations, invoices, recognized costs	Finance / ERP	Governed reservation API with version check; reporting export; reservations remain ERP-owned	Existing-module candidate; supplies part readiness and authoritative reservation confirmation
P03	Dynamics 365 Field Service	Work orders, technician skills, dispatch schedules, visit status	Service operations	Work-order read and proposal-submit adapter; dispatcher approval remains required	Strongest existing-module candidate and scheduling authority
P04	Power Apps / Power Automate environment	Approved departmental forms and lightweight approvals	Business applications	Governed connectors and environment boundaries; complex recovery needs a prototype	Low-code composition candidate; not presumed licensed or sufficient for this workflow
P05	Microsoft 365: Teams, SharePoint, Outlook	Collaboration, controlled documents, human notifications	Workplace IT	Teams notification endpoint and approved document links	Notify users and publish procedures; messages do not approve commitments
P06	Workday	Employment, organizational hierarchy, leave	HR	Restricted workforce export; no salary data to this app	Supplies availability context through approved planning reports only
P07	Microsoft Entra ID	Employee identity, group assignment, access lifecycle	Identity team	OIDC sign-in and scoped service identities assumed	Login, role mapping, deprovisioning; do not create a second user directory
P08	ServiceNow ITSM	Incidents, service ownership, operational change records	IT operations	Incident creation/update adapter and change links	Support, escalation, release change record; not the customer-service process store
P09	Tableau	Approved business reporting and performance dashboards	Analytics	Curated reporting dataset with documented definitions	Compare commitment outcomes and cost; no operational write-back
P10	Enterprise warehouse on Azure SQL	Historical service, finance, and workforce reporting	Data platform	Batch ingestion of approved reporting exports	Establish baseline and benefits; avoid using delayed warehouse data for live reservations
P11	Azure application hosting and managed PostgreSQL	Application runtime and application-owned transactional data	Platform engineering	Private network, backups, deployment identities assumed	Host new coordination service if selected
P12	Azure Key Vault	Application secrets and controlled key access	Security / platform	Managed identity integration assumed	Secrets and rotation; no secrets in templates or generated repositories
P13	GitHub Enterprise and GitHub Actions	Source, pull requests, build execution, release metadata	Developer platform	Protected branches and environment approvals assumed	Existing code/release path; validate configured controls rather than assume defaults
P14	Azure Container Registry	Built deployable artifacts	Developer platform	Immutable digest references and retention policy assumed	Promote identical build across staging and pilot
P15	Jira	Delivery work, bugs, dependencies, sprint commitments	Engineering operations	Project links and controlled automation	Keep as delivery system of record; do not add Vector merely to duplicate it
P16	Azure Monitor and application telemetry	Runtime metrics, logs, traces, alert signals	SRE	Service dashboard and paging integration assumed	Reliability evidence and alerts; redact customer-sensitive fields
P17	Enterprise dependency and container scanning pipeline	Dependency/license findings and vulnerability evidence	Application security	CI reports tied to build identity	Secure build checks; release policy is a company decision
P18	Controlled backup and recovery service	Database recovery copies and recovery records	Platform operations	Encrypted backups, restore testing, access separation assumed	Restore workspace state; upstream reservation reconciliation is still required

Arcore tools considered for the delivery process

Harborline does not adopt the full portfolio. These are proposed pilot uses, subject to validation. A reviewed export is acceptable where no connector is verified.

App	Decision for this case	Purpose and boundary
Genesis	Pilot	Record the problem, options, business case, and funding decision; link to existing portfolio records
Scope	Pilot	Refine requirements and acceptance criteria; Jira retains execution status
Blueprint	Pilot	Version specifications, decision records, and evidence links; verify approval behavior before reliance
Schema	Pilot	Model workspace entities and ownership; review exports and implement migrations through ordinary engineering
Foundry	Conditional two-service pilot	Generate the workspace API and a reusable integration-worker baseline; templates need a platform owner and maintenance budget
Test	Pilot	Catalog cases and results from existing test runners; validate imports and build association
UATCLI	Conditional	Export business acceptance evidence only if the external UAT server is separately provisioned and validated; otherwise use controlled evidence files
Nexus	Read-only pilot	Aggregate normalized service health; existing telemetry and ITSM retain alerts and incidents
Proof	Pilot	Organize incident hypotheses, reproduction evidence, and findings; link to ServiceNow
Chronos	Read-only planning input	Approved effort actuals; not future staff availability
Fiscal	Edge / planning input	Approved expense and billing context for cost forecasts; internal cost rates remain separately governed
Ledger	Edge / planning input	Funding envelope and commitments; finance confirms reconciliation against ERP actuals
Vector	Defer	Jira already owns delivery; revisit only if a demonstrated capacity gap justifies replacement or limited reporting
Parkour	Defer	Existing GitHub Actions deployment path meets this pilot's need; an additional orchestrator adds integration cost
Sentinel / Narrator	Evaluate later	Existing runners and reviews are sufficient for pilot; evaluate specific gaps before adoption
SyncBridge	Defer	Teams notification adapter and SharePoint procedures meet the initial reporting need
StratCore	Assessment pending	Source unavailable; no capability is inferred from the name

Other portfolio applications remain governed by the master checklist. Their omission from the pilot is not a judgment that they have no enterprise use.

Data boundaries

The workspace owns coordination, including commitment versions, prerequisite observations, exception decisions, and audit events. It references CRM account IDs, ERP reservation IDs, and field-service work-order IDs. It does not become a replacement CRM, inventory ledger, dispatch engine, payroll store, or invoicing system.

An upstream timestamp is not proof of a reservation. A cached stock quantity is not permission to allocate a part. A proposed time is not a confirmed visit. These distinctions drive both the requirements and the final architecture.

The pilot processes customer business contact details and work-order references, not payment-card data, technician medical details, or HR compensation records. The security and records owners define access, retention, deletion exceptions, and audit retention before release; the story does not assert any jurisdiction-specific legal requirement.