Automated shop floor device provisioning reduced onboarding from 3 days to 2 hours

I wanted to share our implementation of automated shop floor device provisioning that dramatically reduced our device onboarding time. Before automation, provisioning a new production workstation (barcode scanner, touchscreen terminal, label printer) took 3 days of manual work per device - creating device records in CloudSuite, configuring network settings, installing certificates, setting up user access, and testing connectivity.

With 15-20 new devices per quarter and frequent device replacements, this was consuming significant IT resources and causing production downtime. We built an automation solution using Infor OS APIs and Mongoose scripting that reduced provisioning time to under 2 hours per device, with most of that being physical installation. The configuration and CloudSuite integration now happens automatically.

The solution uses a provisioning workflow that technicians trigger by scanning a QR code on the new device. The workflow handles device registration, certificate deployment, access configuration, and connectivity testing without manual intervention. We’ve provisioned 47 devices since implementation with zero configuration errors. Happy to share technical details if anyone is interested in implementing something similar.

What about certificate management? That’s always the most painful part of device provisioning for us. Are you using Infor OS certificate services, or did you build custom certificate deployment? Also, how do you handle certificate renewal - is that automated too, or still manual?

Sure! The architecture has three main components: a lightweight provisioning agent that runs on each new device, a Mongoose script that orchestrates the provisioning workflow, and integration with Infor OS APIs for device registration. The QR code contains a unique device identifier and provisioning token. When scanned, the agent authenticates with our provisioning service using the token, then the Mongoose script takes over to configure everything. The script calls CloudSuite APIs to create the device record, assign it to the correct work center, and configure user access based on the device type and location.

Certificate management was definitely the trickiest part. We use a hybrid approach - Infor OS certificate services for device authentication certificates, and our internal PKI for SSL/TLS certificates. The Mongoose script generates a certificate signing request during provisioning, submits it to Infor OS certificate services, and automatically installs the signed certificate on the device. Certificate renewal is also automated - we have a scheduled job that checks certificate expiration dates and triggers renewal 30 days before expiration. The device gets the new certificate automatically without any production interruption.

Great questions from everyone. Let me provide comprehensive technical details covering all three focus areas:

Device Management API Integration:

The core of our solution leverages Infor OS Device Management APIs for device lifecycle management. Here’s the high-level API workflow:

  1. Device Registration:
// Provisioning agent calls registration endpoint
POST /api/v1/devices/register
{
  deviceId: scanQRCode(),
  deviceType: 'PRODUCTION_TERMINAL',
  location: 'PLANT-01-LINE-03',
  provisioningToken: extractToken()
}
  1. Device Configuration: The API returns a configuration payload that includes network settings, work center assignment, and user access profiles. The agent applies these settings locally, then confirms configuration success back to the API.

  2. Connectivity Testing: The Mongoose script orchestrates automated connectivity tests - pinging CloudSuite endpoints, testing API authentication, verifying printer connectivity, and validating barcode scanner integration. All test results are logged to Infor OS for audit purposes.

  3. Reprovisioning Support: For device replacements, we implemented a decommission-and-replace workflow. When a technician scans the QR code with a replacement device identifier, the Mongoose script:

  • Checks if a device record with that serial number already exists
  • If yes, marks the old device as decommissioned and transfers its configuration to the new device
  • Preserves work center assignments and user access settings
  • Archives the old device record for compliance tracking

This means replacement devices inherit the exact configuration of the device they’re replacing, eliminating configuration drift and errors.

Mongoose Scripting for Orchestration:

The Mongoose provisioning script handles the complex orchestration logic that coordinates between the device agent, Infor OS APIs, CloudSuite configuration, and certificate services. Key script components:

  1. Workflow State Machine:
// Pseudocode - Key provisioning workflow:
1. Validate provisioning token and device identity
2. Query CloudSuite for work center and location data
3. Generate device configuration based on device type
4. Create device record in CloudSuite via API
5. Initiate certificate signing request workflow
6. Deploy certificates to device via secure channel
7. Configure network settings and firewall rules
8. Assign user access profiles based on location
9. Execute connectivity test suite
10. Mark device as provisioned and ready for production
// See documentation: Mongoose Provisioning Guide Section 3.4
  1. Error Handling and Rollback: The script implements transactional provisioning with automatic rollback on failure:
  • Each provisioning step creates a checkpoint in MongoDB
  • If any step fails, the script executes a rollback procedure that reverses all completed steps
  • Rollback includes: deleting the device record from CloudSuite, revoking certificates, removing network configurations
  • The device returns to unprovisioned state and can be re-attempted
  • All failures are logged with detailed error context for troubleshooting
  1. Certificate Lifecycle Management: The most complex part of the script handles certificate provisioning and renewal:
// Certificate request and installation flow
function provisionCertificate(deviceId) {
  const csr = generateCSR(deviceId);
  const signedCert = inforOS.certificateService.sign(csr);
  deviceAgent.installCertificate(signedCert);
  scheduleRenewal(deviceId, cert.expirationDate);
}

We use Mongoose’s scheduled job capability to check certificate expiration daily. When a certificate is within 30 days of expiration, the script automatically generates a new CSR, gets it signed, and deploys the new certificate to the device. The old certificate remains valid until the new one is confirmed operational, ensuring zero-downtime certificate rotation.

  1. Configuration Templates: The Mongoose script uses configuration templates stored in MongoDB that define standard settings for each device type:
  • Production terminals: Touchscreen calibration, barcode scanner settings, label printer configuration
  • Quality inspection stations: Camera settings, measurement tool integration, defect tracking configuration
  • Inventory scanners: RFID reader settings, batch scanning mode, offline operation parameters

Technicians can customize templates without modifying the script, making the solution adaptable to different production environments.

Provisioning Workflow Implementation:

The end-to-end provisioning workflow from a technician’s perspective:

  1. Physical Installation (60 minutes):

    • Mount device at workstation
    • Connect power and network cables
    • Boot device (auto-loads provisioning agent)
  2. Automated Configuration (15 minutes):

    • Technician scans QR code on device label
    • Agent authenticates and downloads device profile
    • Mongoose script executes provisioning workflow
    • Device automatically reboots with production configuration
  3. Validation Testing (45 minutes):

    • Technician performs operational tests: scan test barcode, print test label, log in with test user
    • Automated connectivity tests run in background
    • Script validates all tests passed and marks device production-ready
    • Notification sent to production supervisor that device is available

Business Impact:

  • Provisioning time: 3 days → 2 hours (93% reduction)
  • Configuration errors: 15-20% → 0% (47 devices with zero errors)
  • IT labor: 24 hours per device → 2 hours per device (92% reduction)
  • Production downtime: 4-6 hours per device → 0 hours (devices provisioned during shift changes)
  • Annual cost savings: $127K in IT labor + $43K in avoided production downtime

Lessons Learned:

  1. Certificate management is the hardest part - invest time in getting the certificate workflow right
  2. Rollback capability is essential - failed provisioning attempts must leave devices in clean state
  3. Configuration templates make the solution maintainable - avoid hardcoding device settings in scripts
  4. Comprehensive logging is critical for troubleshooting - log every API call, every configuration change, every test result
  5. Reprovisioning is just as important as initial provisioning - design for device replacement from the start

The Mongoose scripts and device agent code are available in our internal GitHub repository. If there’s interest, I can work with our legal team to open-source the provisioning framework. The implementation is CloudSuite-specific but the architecture and patterns are applicable to any ERP system with REST APIs and certificate-based device authentication.

How do you handle device failures or reprovisioning? If a device needs to be replaced, can you use the same automation, or does it require manual cleanup of the old device record first? We have a lot of devices that fail and need replacement, so the reprovisioning workflow is just as important as initial provisioning for us.

What about rollback capabilities? If the automated provisioning fails partway through, how do you clean up partial configurations?

This sounds exactly like what we need. We’re still doing manual device provisioning and it’s a nightmare - inconsistent configurations, frequent errors, and way too much time spent on repetitive tasks. Can you share more about the architecture? What components are involved and how does the QR code trigger the workflow?