RESOURCES / TECHNOLOGY EXPLAINED
Configure, integrate or build custom software?
These are different ways to meet a business requirement, and one project may use all three. Start with the workflow, data and controls you need; then compare what existing software can do with what must be connected or created.
Configuration: change settings within an existing product
Configuration uses capabilities a product already provides: fields, forms, roles, notifications or approval rules. It can fit when your process matches the product’s underlying records and workflow.
The constraint is the product’s model. A custom field does not necessarily support a new relationship, permission rule or approval state. Before choosing this route, test the hardest requirement using representative data and the actual user roles. Ask what can be exported and who controls the account.
Integration: connect systems without confusing ownership
Integration coordinates information or actions across systems. For example, a request form might create an internal work item while a separate customer system remains authoritative for contact details. Decide which system owns each field and which direction changes travel.
An API defines a way software can interact. A webhook sends event information to a receiving endpoint when a subscribed event happens, rather than requiring repeated checks for changes. Neither term means a connection is already implemented or reliable. Authentication, field mapping, errors and operation ownership still need design.
An integration is a good candidate when existing systems each do useful work but manual transfer creates gaps. Its trade-off is dependency: a permission change, unavailable service or changed interface can interrupt the connection. Define reconciliation and failure handling, not just the successful transfer.
Custom software: create behavior the workflow requires
A custom build creates application behavior for requirements that existing configuration and connections do not adequately meet. A purpose-built review screen, specialized record relationship or unusual permission boundary may justify it.
The trade-off is responsibility. Someone must maintain the application, dependencies, access rules and operating documentation. Ask who controls source code, hosting accounts and data exports; who can make changes; and how the system will be recovered or replaced. “Custom” does not automatically mean better, faster or more secure.
A worked comparison
Suppose a team receives requests, checks completeness and asks a designated reviewer to approve them. If its existing platform already supports those records, role restrictions and approval history, configuration may be enough. If approved requests must also create a work order elsewhere, integration may be the missing piece.
If the approval depends on a specialized relationship between several records that the existing platform cannot express, evaluate a custom component. First prove that constraint with an example; do not infer it merely because the current process is inconvenient. These are illustrative options, not a recommendation for a particular organization.
Automation and AI are separate choices
Rule-based automation follows defined conditions: if a required field is missing, return the request for completion. An AI component can propose a category or draft a summary from less structured material, but its output needs evaluation against the task.
An AI agent uses a model to help direct work across steps and tools. That is different from a fixed sequence of rules, and it does not remove the need for permissions, stopping conditions or approval. Keep consequential actions behind an appropriate review boundary; a generated explanation is not evidence that a source record is correct.
Five questions to compare options
Can the approach represent our actual records and exception paths? Can each role be restricted to the right actions? Can we identify and recover from a failed update? Can we export the information we need? Who is accountable for maintaining it?
Compare the total operating arrangement, not only the initial feature list. An option that satisfies the normal path but cannot explain ownership, exceptions or exit requirements is not yet a complete proposal.
Technology Solutions & Business Services