Problem

The Business Central Performance Toolkit (BCPT) is the official and recommended way to measure performance, detect regressions, analyze bottlenecks, and validate solution scalability. However, BCPT cannot currently be automated in any way because:

• All BCPT objects are marked Internal.
• No public API, event, interface, or codeunit allows triggering a BCPT Suite programmatically
• Job Queue cannot execute BCPT scenarios.
• Extensions cannot integrate with BCPT, even though this is aligned with best practices for DevOps and continuous performance validation

As a result, partners are unable to run scheduled performance tests from pipelines or job queue, even though Microsoft’s own performance guidance (telemetry, profiling, BCPT usage) strongly recommends recurring testing to detect performance regressions early.

This limitation is particularly impactful in SaaS, where environments receive monthly updates and performance characteristics may change.

Suggested Solution

Expose a public entry point for executing BCPT Suites programmatically.

This could be any of the following:

1. A new public Codeunit, e.g.: codeunit BCPT Public Runner with a method RunSuite(SuiteFilter: Text)
2. A public interface with a default implementation
3. An Event Publisher in the current internal BCPT runner
4. A new AL API object specifically for performance-test automation with Service-to-Service integration.

The required functionality is minimal: allow specifying Suite Code filter(s) and trigger execution in the same way the BCPT UI does today.

How the Feature Should Work

1. A consultant creates a standard Job Queue Entry
2. Sets:

• Object Type: Codeunit
• Object ID: Public BCPT Runner
• Parameter String: Suite filter (e.g. "Suite Code=PERF*")

1. The Job Queue passes this filter to the public method
2. BCPT runs the suite(s), logs results, and emits telemetry exactly as it does today in manual execution

This approach follows the established pattern of Job Queue extensibility that Microsoft already uses for other system-level operations.

Why should this be implemented?

1. It aligns with Microsoft’s own performance methodology

BCPT is a core component in troubleshooting performance, as presented in Microsoft sessions on performance tuning and BCPT usage. Being unable to automate BCPT prevents partners from following best practices.

2. It enables continuous performance validation

Performance regressions often appear after monthly updates or code deployments. Scheduled BCPT execution would allow early detection of degraded performance, deadlocks, locking patterns, or long-running queries.

3. It unlocks DevOps scenarios

Without a public API, CI/CD pipelines cannot include performance tests, which contradicts modern engineering standards.

4. It improves the stability of BC Online tenants

Regular performance tests improve database access patterns and lower the risk of resource contention — indirectly improving Microsoft’s infrastructure health.

5. No viable workaround exists

• Extensions cannot use Internal objects.
• Job Queue cannot call BCPT
• PowerShell runners cannot be scheduled inside the tenant
• There is no automation point in SaaS

This feature would unlock a missing capability without changing existing BCPT logic. There is no valid workaround in SaaS.

Partners cannot legally or technically access internal BCPT objects. No automation can be built today without an unsupported reflection or copying toolkit code.