Solution Delivery
What Solution Delivery covers
Solution Delivery covers the lifecycle from build to production: packaging a release, moving it between environments (development, test, production), and operating it. Candidates must understand release packages, versioning, the contents of a release (processes, objects, queues, credentials references, environment variables), and the import/export process. Also understand testing levels - unit testing of actions, process testing, and user acceptance testing - and the use of a controlled test environment with representative data.
Operational concepts matter too: queue configuration (priorities, retry limits, maximum attempts), scheduling with timetables and schedules, session management, and monitoring through logs and dashboards. A candidate should know that environment-specific values belong in environment variables so the same release can be promoted unchanged.
Traps in questions
Typical traps: editing a process directly in production instead of promoting a tested release; embedding environment-specific paths or URLs in the process; assuming a release carries credentials (it does not - references do); and treating a successful process test as sufficient without action-level unit tests. Questions also test retry behaviour: an item exceeding maximum attempts is marked as an exception, so retry limits must be set deliberately.
Worked example
A release is built in development, unit-tested action by action, then run against a test queue with representative volumes to measure throughput and confirm recovery. Environment variables hold the URLs and file paths for each environment. The same package is imported to production, credentials are re-pointed, and the schedule is enabled. If a production run fails, the queue item is retried up to its maximum attempts before being exceptioned for review.