Boomi Architect common mistakes
Boomi Architect · Understand the traps and how to avoid them.
Designing every flow as a single large process with many shapes on one canvas instead of decomposing it into subprocesses and reusable components.
Candidates treat the exam like a build exercise and optimize for getting data from A to B, missing that architect-level questions reward modularity, reuse, and separation of concerns.
What to do instead
Before answering design scenarios, sketch the component boundaries: identify which logic repeats across flows and should become a subprocess or shared process, and justify the split by maintainability and testability rather than by shape count.
Assuming a process will retry or recover on its own and ignoring the difference between document-level errors, shape-level failures, and connection failures when describing error handling.
In practice many developers rely on default behavior and manual reprocessing, so they never internalize which failure class needs a try/catch path, a retry with backoff, or a dead-letter route.
What to do instead
For each failure scenario, classify the failure first, then state the mechanism: catch shape for document processing errors, retry policy for transient connectivity, and a quarantine or error queue for poison messages. Practice naming the layer where each is configured.
Treating API Management as only proxy configuration, and describing policies as a flat list without mapping them to the specific concern they address.
Candidates memorize policy names but not the ordering and interaction between authentication, rate limiting, transformation, and routing, so they pick plausible-sounding policies that conflict or run at the wrong stage.
What to do instead
Build a mental pipeline: authenticate, authorize, throttle, transform, route, log. For each exam scenario, place the needed policy at its stage and explain what breaks if it moves. Study how policy ordering changes behavior, not just what each policy does.
Confusing gateway-level enforcement with backend-level enforcement when answering questions about security and traffic control.
Real deployments often have overlapping controls, so candidates cannot articulate which layer is authoritative and default to whichever term appears in the question stem.
What to do instead
For each control (key validation, quota, schema validation, TLS termination), state explicitly whether it is enforced at the gateway, the API definition, or the backend, and describe the consequence of removing the gateway layer.
Choosing a data mapping approach by habit (scripting versus graphical mapping versus direct profile matching) without weighing volume, maintainability, and schema volatility.
Candidates have a comfort-zone technique from prior projects and apply it universally, ignoring that exam scenarios deliberately vary document size, nesting depth, and change frequency.
What to do instead
Create a decision table: for high-volume flat transformations favor efficient built-in mapping; for deeply nested or conditional logic favor functions or scripts with tests; for frequently changing schemas favor externalized maps. Cite the tradeoff in your answer.
Ignoring data quality and reconciliation concerns, such as duplicate detection, idempotency, and ordering, when describing integration data flows.
Candidates focus on transport and transformation and treat duplicates and out-of-order delivery as edge cases, but architect questions probe them directly because they cause production incidents.
What to do instead
For every flow you design, state the idempotency key, the deduplication window, and the ordering guarantee you rely on. If the source cannot guarantee order, describe the re-sequencing or compensating logic.
Treating master data and reference data as ordinary integration payloads rather than as governed entities with ownership and lifecycle.
Candidates conflate data movement with data management and therefore miss questions about stewardship, golden records, and synchronization direction.
What to do instead
Distinguish transactional, reference, and master data explicitly. For master data scenarios, name the system of record, the synchronization pattern (one-way versus bidirectional), and the conflict resolution rule before describing the technical flow.
Describing AI features as a black box, omitting how context is assembled, chunked, retrieved, and grounded before the model is invoked.
Candidates know the vocabulary of retrieval and embeddings but have not traced a request end to end, so they cannot answer questions about relevance, freshness, or hallucination mitigation.
What to do instead
Practice narrating the full request path: ingestion, chunking strategy, embedding, indexing, retrieval, prompt assembly, model call, and response validation. For each stage, name one failure mode and the control that addresses it.
Ignoring operational concerns for AI workloads such as latency budgets, token cost, rate limits, and fallback behavior when a model or embedding service is unavailable.
Candidates treat model calls like ordinary API calls and do not consider that they are slower, costlier, and more variable, so resilience and cost questions catch them unprepared.
What to do instead
For each AI scenario, state the latency and cost budget, the retry and timeout policy, the caching strategy for repeated prompts or embeddings, and the degraded-mode behavior when the provider fails.
Designing agentic workflows without explicit guardrails, human approval points, and bounded tool permissions, and without a plan for evaluating agent behavior.
Candidates are drawn to autonomy and describe agents as free-roaming planners, missing that architect-level answers emphasize constrained action spaces, auditability, and rollback.
What to do instead
For every agent design, specify the allowed tool set and scope, the approval gate for irreversible actions, the logging and trace requirements, and the evaluation method (task success rate, tool-call accuracy, escalation rate). Describe what happens when the agent is uncertain.