Services — Development, Implementation & Support

How our services are shaped

Services around a catalog, not billable hours around a brief

Infivex is primarily a dealer: we supply business software and hardware, and we build three products of our own. Our services exist to make that supply actually work.

That is a narrower proposition than a general IT consultancy offers, and deliberately so. Our developers spend their time inside Microsoft Dynamics and on the Power Platform around it, and inside SLinkHub, Finly and SLinkHub Screens. Depth in a small number of platforms is the whole point; it is what lets us answer a question about your posting routine without first spending two days reading it.

It also sets a clear boundary. We develop in, extend and support the Dynamics environment you already run, and we implement our own products into it. We do not take on greenfield third-party ERP rollouts — standing up a first ERP for a company that has none is a different discipline, and we will say so on day one rather than discover it in month four.

Three services

Build it, put it live, keep it running

Most engagements touch all three eventually, but they are separate services with separate commercial arrangements — so support capacity is never quietly consumed by project work.

A person typing on a laptop at a desk, with a large monitor behind showing a code editor and a terminal

Development

Extensions inside Business Central, Dynamics NAV, BC - On Premise and Finance & Operations; integrations to webshops, banks, suppliers and logistics; Power Apps, Power Automate flows and Power BI reporting. Standard configuration is always tried first, and everything is delivered in two-week sprints with something to see at the end of each one.

Development →

A woman standing at the head of a meeting table addressing four seated colleagues, with a cork board of sticky notes behind her

Implementation

Two things specifically: putting our own products live inside environments that are already carrying real work, and migrating or upgrading legacy and on-premises Dynamics estates to a current, supported version. Sandbox rehearsal before cut-over, training before go-live, and a defined rollback position.

Implementation →

Five colleagues gathered around an open laptop in a bright office, looking at the screen together

Support

An SLA-backed managed service that absorbs the steady flow of user questions, incidents, small configuration changes and update management. Structured ticketing that builds a knowledge base against your configuration, phone access when a call is faster, and routing straight to a specialist.

Support →

How an engagement runs

Three stages, and no theatre in between

There is no branded methodology here with a fixed number of phases and a diagram to match. There is a requirement, a short build cycle, and a service that carries on afterwards.

Understand the requirement

What the business actually needs, what the platform already does that nobody switched on, and what is genuinely missing. A surprising share of requests end here, because the answer turns out to be a configuration change rather than a project — and we would rather tell you that than quote for it.

Build or configure in short cycles

Two-week sprints with something concrete to see at the end of each. Priorities can move between sprints without derailing anything, because nothing has been built six months ahead of the decision that justifies it. Everything is proven in a sandbox before it goes near production.

Go live, then stay

Training before cut-over, a defined switch with a fallback position, and monitoring in the weeks afterwards. Then it transitions into the SLA — supported by the same people who built it, with extensions checked against each platform release.

What is consistent across all three

The same people, the same platforms, the same standards

Whichever service you engage, the work lands with a team that already knows the platform and, after the first engagement, knows your configuration too.

Built the supported way. Extensions use Microsoft's extension model, so an update is a scheduled event rather than an emergency.
Sandbox before production. Nothing is tried for the first time on a live company — not a migration, not an update, not a new extension.
Continuity of people. You are not re-explaining your business on each call, and the person who wrote the code is reachable when it misbehaves.
Advance notice of platform releases. Updates tracked, tested and scheduled around your operational calendar rather than dropped into month-end.
Our own products included. SLinkHub, Finly and SLinkHub Screens are developed, implemented and supported by the same team, not handed to a reseller channel.

How we work

Sprint length: 2 weeks
Pre-production testing: Sandbox
Support model: SLA-backed
Phone support: Available
Update compatibility: Monitored

Business Central Dynamics NAV BC - On Premise Finance & Operations Power Platform Azure

Scope

What we don't do

Stating this plainly saves everyone time, and it is the fastest way to tell whether we are the right supplier for the thing you are currently trying to solve.

No greenfield third-party ERP rollouts. We do not stand up a first ERP for a company that has none. We build in, extend and support the Dynamics environment you already run, and we implement our own products into it. If a full replacement is what you need, we will say so early and point you toward a firm that runs those properly.
No body-shopping or staff augmentation. We do not place developers into your team by the month to work under your management. We take responsibility for a deliverable or a service, which is a different arrangement and produces a different result.
No general-purpose IT helpdesk. Laptops, printers, mailboxes and the office network belong with your IT provider. Our support covers the software we supply and the Dynamics environment it runs in — that is where our answers are worth having.
No work we would do badly. If a request sits outside what we know well, the honest answer is no. It is a short conversation and it costs you nothing, which is more than can be said for the alternative.

Check whether we fit Microsoft at Infivex

Questions

Services FAQ

Case by case, and the honest answer is sometimes no. Dynamics environments implemented by another partner are familiar territory — we review the existing configuration first, so we know what we are taking on before the agreement starts rather than learning it one incident at a time. Software outside that world is a different question, and if we cannot support it to the standard we would want, we will say so rather than take the contract and do it badly.

It defines in advance how requests are handled and what you can expect, so priorities are agreed before an incident rather than negotiated during one. Requests arrive by ticket or by phone and land in the same tracked queue, get routed to a consultant with the relevant expertise instead of a generic first line, and are recorded so the answer is available next time. Update management is part of it, not an extra. The full detail is on the support page.

It depends on how well the scope can be pinned down. A defined piece of work with clear boundaries can sensibly be fixed; open-ended development where priorities move between sprints usually should not be, because a fixed price on a moving scope only produces an argument later. Support runs as a service agreement rather than per incident. We will tell you which shape fits your request before quoting it.

Stabilization first — monitoring and adjustment in the weeks when the real edge cases surface — and then a transition into the SLA-backed support service. The same team stays on it. Anything custom we built is monitored for compatibility with each platform release, so a Microsoft update does not quietly break something you depend on.

Yes, within the platforms we work in. A handover starts with a review of the environment as it actually is: versions, extensions, integrations, customizations and whatever documentation exists. That review sometimes changes the conversation — occasionally what looks like a support problem is really an architecture one — and it is far better to establish that before an agreement than after.

The work that surrounds the software we supply