OUR INTEGRATION MODEL

Your systems.
Our work, under your direction.

We design, build, and maintain connections as a contractor authorized by your business. You retain control of your environments, users, client-owned applications, and credentials.

WHY CUSTOMER OWNERSHIP MATTERS

The connection should stay with the business.

An office may need a workflow that its existing software does not provide out of the box. A customer-owned integration can address that specific need while keeping the accounts, operating decisions, and agreed deliverables with the business.

This is our delivery model where the vendor supports it. It is not a universal platform requirement or a substitute for vendor approval. Before a build, we confirm the permitted application type, account eligibility, required permissions, and who controls the software that will actually run.

Your businessOwns the accounts · authorizes access · approves changes

AGREED DATA FLOW / SUBJECT TO VENDOR REQUIREMENTS

Website & phonesAgreed source records
Your integrationClient-owned app and agreed runtime
Field service softwareClient-managed environment

Your administrators control vendor accounts and credentials. Hosting control is documented separately.

TackScoped design, build, QA, documentation, training, and maintenance
Access authorized by the client
Illustrative responsibility model. The project scope records the actual ownership, hosting, access path, and data flow. Connections between systems do not imply permission to share credentials.

WHO CONTROLS WHAT

Separate ownership
from the work performed.

Registering an app and owning the software behind it are different. We make both explicit in the agreement.

Client and contractor responsibilities
Part of the engagementThe client controlsTack does
Business and software accountsThe client owns its vendor relationships and controls its tenant configuration, users, billing, and account recovery.We assess requirements and implement scoped changes through the access the client and vendor permit.
Developer registration and appThe client registers and controls its own developer portal app where that model is supported and approved.We guide registration, document required scopes, and build or maintain the agreed client-owned application.
Credentials and authorizationThe client’s administrator manages credential creation, storage, rotation, access approval, and revocation.We document access needs and use only the vendor-permitted contractor access assigned for the project.
Code, configuration, and runtimeThe client approves the hosting arrangement and agreed code, configuration, and handoff rights. The agreement identifies the actual hosting account owner and administrators.We design, build, test, document, and maintain the scoped work. Hosting may be client-managed or provided under a separate agreement where vendor requirements permit.
Data and operationsThe client approves the data involved, the permitted destination, the office owner, and the operating requirements.We apply scoped validation, monitoring, exception handling, and training within the vendor’s data-use and retention rules.

ACCESS HAS A START AND AN END

Authorize. Review. Revoke.

A written scope identifies the work, the people allowed to perform it, and how access ends.

01

Authorize the agreed work.

Confirm the vendor’s supported route and any required approval. Your administrator completes authorization and assigns the narrowest permitted contractor access. Passwords and secrets do not belong in a consultation request.

02

Review while work is active.

Maintain an access inventory without copying secret values into it. Record purpose, permissions, administrators, renewal dates, data destinations, and changes. Revisit access when scope or staffing changes.

03

Revoke and hand over.

Follow the vendor’s process to remove users or grants, disconnect apps, and rotate or revoke credentials where required. Verify that access stops, transfer the agreed documentation, and complete required data deletion.

A DEFINED OPERATING ARRANGEMENT

What this model requires.

Clients are responsible for authorizing and managing access in accordance with their software vendors' applicable terms and policies.

DEFINE THE WORK BEFORE THE BUILD

Map the right access path first.

Tell us what your team is working through, which tools are involved, and what you want to happen next.

Discuss your project