Introduction
This page is designed to tackle the frequently asked questions we already expect partners and customers to ask about ARVO Studio. Each answer links to the article that covers the subject in full, so use this page to get a quick, reliable answer and follow the link when you need the detail.
1. Can I install ARVO Studio in Production?
No. ARVO Studio is sandbox-only by design and by licence, so a Production environment is never a valid installation target. Production receives only the approved solution app, through gated promotion, and ARVO Studio and the test app never go there. Install ARVO Studio from AppSource covers the installation itself, and Promote explains how the approved app reaches Production.
2. Is AI usage included?
No. AI runs on your own Azure AI Foundry deployment or Anthropic account, and you pay the provider directly for what you use. Bluefort does not resell, supply or absorb AI capacity, so AI consumption is never part of the ARVO fee. Your Azure AI (BYO) and Your Anthropic API (BYO) explain how to connect your own account, and Token Estimation explains the estimate you see before a build is approved.
3. Can I move an entitlement to another customer?
Yes, once 90 days have passed since its most recent activation. Deactivating earlier does not release the entitlement any sooner, because it stays consumed until that 90-day point is reached, after which it can be reassigned to another environment or tenant. Deactivate and reassign sets out the rule with worked examples.
4. Where did my background job go?
Completed jobs leave the active queue, so a job you can no longer see on Background AI Jobs has most likely finished rather than disappeared. Their results remain in Runs, which holds the project execution history. Background AI Jobs describes the active list, and When a run parks explains what to do if a job stopped for human review instead of completing.
5. What happens if I deactivate the environment?
Projects stay readable and nothing is deleted. AI actions stop for that environment and the sandbox moves into a reduced mode, but existing projects, artefacts and records remain available and ARVO Studio is not uninstalled. Deactivate and reassign explains what changes and what does not.
6. “Tested before the code exists”: does this mean the test suite is written from the design and frozen?
Yes, that is the principle, although “tests defined before the code exists” would be more accurate wording.
ARVO prepares the test cases and expected outcomes from the functional and technical design, with human review and approval before code generation. Those approved test definitions are then frozen. Once the solution and executable test app have been built, the tests run in the sandbox against prepared test data.
The distinction matters: the implementation is judged against requirements agreed beforehand. The repair process can change the code to meet those requirements; it cannot quietly change the tests to make failing code pass. If an approved test needs correcting, that goes back through review.
7. Is ARVO primarily for partner firms that do not yet have advanced AI development skills in-house?
Those firms are an important audience, but the opportunity is broader.
Some BC developers already achieve impressive results with AI. ARVO brings requirement analysis, design, generation, testing, approvals and deployment into one governed process, carrying the context and evidence throughout. For a partner developing its AI capability, that provides a structured way to scale delivery. For an advanced partner, the value is making its delivery standards repeatable across the practice, rather than dependent on a few specialists.
Functional consultants play a central role: defining the business need, reviewing the proposed solution and judging whether it meets the customer’s requirements. Technical expertise remains important for complex decisions and exceptions.
8. Is Bluefort/ARVO participating in community open-source projects for AI-driven BC development?
We have no formal participation in a specific community project to announce at this stage. ARVO builds on Microsoft’s BC development interfaces, AL compiler and testing framework.
We recognise the value of the community’s work on AI development practices and standardisation. Using those foundations and contributing to a particular open-source project are different things, and we would only claim participation where we can point to a concrete contribution.
9. Do partners need guidance on how an ARVO engagement differs from a traditional 30-day customization?
Yes. Faster generation changes how the work is organised, but the partner still needs to understand the customer’s problem, agree scope and exercise professional judgement.
Enablement needs to cover how to prepare a clear requirement, review the design and acceptance criteria, interpret test evidence, manage changes and approve release. It also needs to address commercial practice: when to prototype, how to price the outcome and how to explain the deliverables to the customer.
The aim is to spend less effort producing and repeatedly reworking the implementation, while keeping the decisions that determine whether it is the right solution.
10. How many customers will be affected by the ending of SOAP and OData endpoints?
There is an important distinction here: Microsoft is not ending all OData endpoints.
Its published guidance removes the ability to expose Microsoft UI pages as SOAP endpoints in BC version 29, and as OData endpoints in version 30. SOAP more broadly is deprecated, with removal planned for a future release. Dedicated API pages and queries are the recommended direction.
We do not have a defensible percentage of customers affected. The impact depends on which endpoints their integrations actually consume, rather than simply whether they use web services.
Partners should inventory published services and check usage and dependencies. Affected integrations need assessment on both sides: providing a replacement BC endpoint may also require changes to the consuming application. This is a concrete modernisation use case for ARVO, rather than a claim that every customer needs its customisations replaced.
Microsoft’s guidance: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/deprecated-feature…
11. How does ARVO reduce functional analysis and design from five days to two?
The five-to-two-day example illustrates the potential reduction for a suitably scoped requirement; it should not be read as a universal benchmark.
ARVO accelerates the work around the consultant’s judgement: analysing requirements against standard BC capabilities and the installed application context, drafting gap analysis and functional and technical designs, and preparing linked acceptance criteria and test cases. These outputs share the same context, reducing repeated documentation and handovers.
The consultant still validates the business process, resolves ambiguity and approves the design. The saving comes from reaching a coherent, reviewable design faster. Actual effort depends on requirement quality, complexity and how many business decisions remain unresolved.