Blog

Insights & ideas

Stay ahead with expert articles, industry trends, and actionable insights to help you grow.

10 mins read

December 3, 2025

Is Agent 365 the moment enterprise AI becomes real?

Agent 365 is the moment AI enters the enterprise stack with real identities, permissions, and governance. Before this becomes your new operating model, you’ll want to understand what’s coming.

TL;DR

A365 is Microsoft’s new identity, governance and management layer for AI agents, giving each agent its own permissions, lifecycle, audit trail and operational controls. It's a signal that AI isn’t a side feature anymore; it’s becoming a governed, scalable digital workforce inside the enterprise stack. Instead of scattered pilots and experimental bots, enterprises get a unified way to build, manage and scale agents across CRM, ERP, HR, finance and data workflows. This is the shift from “AI as a helper” to “AI as part of the workforce,” and it raises a simple question: are you preparing your processes, data and governance for digital labour, or will you be catching up later?

How will Agent 365 reshape the way organisations work?

Most organisations spent the last year wrapping their heads around Copilot: what it can do, where it fits, and how to introduce it without overwhelming employees. But while everyone was busy figuring out prompts and pilots, Microsoft was preparing something far bigger.

Agent 365 is the moment enterprise AI stops being a clever assistant and becomes a managed digital workforce.

There’s an important detail that wasn’t obvious at first: the A365 icon sits inside Microsoft’s AI Business Applications stack, the same family as Dynamics 365 and the Power Platform. What looked at first like a Modern Work / Office feature is actually positioned alongside enterprise-grade business applications.

And they gave it the “365” name. When Microsoft attaches “365” to a product, it becomes part of the workplace operating system. SharePoint, Teams, Excel, Dynamics. These aren’t just tools, they’re the foundation of daily work. This isn’t accidental positioning; putting agents in the 365 family, Microsoft is sending a clear message:

AI agents are not experiments anymore. They are part of the enterprise stack.

And this has huge implications for IT Ops, Security, CoE teams, and business leaders.

From scattered bots to a unified agent ecosystem

If you’ve worked with Copilot Studio or any of the early Microsoft agents, you know the experience hasn’t been consistent. Agents lived in different places, were created in different ways, and had different capabilities. Some behaved like chatbots, others like automations. A few acted like full digital workers, if you were brave enough to give them permissions.

Agent 365 is the first attempt to bring order to this chaos. Instead of agents scattered across the Microsoft ecosystem, there will be one place to see them, manage them, and govern them. Microsoft calls it the Monitoring Admin Center, where agents are treated like real operational entities.

For the first time, IT teams can:

see all agents in one view

assign their own permissions

scale them independently

isolate them if needed

monitor activity

apply governance policies the same way they do for users

This is the shift organisations have been waiting for. AI is no longer a set of small tools you sprinkle across teams. It becomes a proper enterprise layer, where you can administer, secure, and scale agents.

Copilot vs Agent 365

What’s the difference? A useful way to think about it:

Copilot is the interface where people talk to AI.

Agents are the products the AI performs the work with.

Copilot will remain the interaction layer used across Microsoft products, but the deeper AI ecosystem (the one that will actually power work) is Agent 365.

This means that agents are moving into infrastructure territory.

A unique identity for every agent changes everything

The most important and least understood part of the announcement is Microsoft Entra Agent ID.

Until now, most AI agents have run under user identities, app registrations, or custom service accounts. Agent ID introduces a new, first-class identity type in Entra that is purpose-built for agents.

With Agent ID, an enterprise agent can finally have:

its own identity in Entra

its own assigned permissions instead of inheriting a user or app profile

its own access and governance policies, including Conditional Access

its own lifecycle management (creation, assignment, decommissioning)

its own auditability, with logs that show what the agent did and when

its own compliance surface, so organisations can apply the same Zero Trust, monitoring and oversight they use for other identities

In short: Agent ID gives agents a proper identity layer, separate from people and apps, and creates the foundation for secure, governed, enterprise-grade agentic automation.

You’re no longer tying a bot to a user’s permissions and hoping nothing goes wrong. You can now manage a digital worker with the same clarity as a human one, without the HR paperwork.

For IT Ops and Security teams, this is the part that makes scalable AI realistic. Without clear identity, real autonomy is impossible. Agentic ID is the foundation for everything Microsoft wants to build next.

Tools turn agents into real digital workers

Early AI agents were impressive but limited. They could answer questions or summarise documents, but they couldn’t do much.

Agent 365 changes that by introducing a real tool model: secure, isolated, pre-defined capabilities that agents can invoke to complete tasks on your behalf.

This brings a new class of role-specific agents. Some use cases we expect to see soon:

An agent with invoice-reading capabilities can take on routine finance tasks.

An agent that can post into your ERP can handle basic accounting work.

An agent that can update your CRM can manage SDR-level activities.

In other words: your business systems stay the same, but what your agents can do inside them expands dramatically.

The tools define the scope of work, and the governance layer defines the boundaries.
Once those two connect, something significant happens:

AI stops being a helper and becomes a decision-maker. That’s why companies need structure, identity, and controls before they deploy anything serious. And this is exactly what Agent 365 provides.

Microsoft will ship out-of-the-box agents

Microsoft doesn’t hide the direction anymore: they’re building their own out-of-the-box agents for major business functions.

Expect products like:

Sales Development Agent

HR Lifecycle Agent

Customer Service Agent

Finance/ERP Agent

Fabric Data Agent

Security and Compliance Agents

These will be real, supported Microsoft products. And they will almost certainly be licensed per agent, just like every other 365 workload.

This will raise important organisational questions:

"How many agents do we need?"

"Which roles replace manual steps with agents first?"

"Should we start with one per department or buy bundles?"

"What does ROI look like at the agent level?"

Licensing will likely become more complex; but the value will grow even faster for organisations that introduce agents deliberately, not reactively.

Where businesses will see early wins

In the next 12 months, the most realistic value will come from processes that already run inside Microsoft systems and already require repetitive, structured work:

Sales teams cleaning pipelines

Finance teams processing invoices

Customer service teams triaging cases

Data teams preparing datasets

HR teams onboarding people

Anywhere a human currently moves structured data between structured systems, an agent will do it faster, cleaner, and more consistently.

And the mistakes to avoid

Agent 365 brings enormous potential, but, like every major Microsoft release, it also comes with predictable, avoidable traps.

As with every AI initiative, readiness is key. Before you commit to licences, tools or departmental rollouts, make sure you’re not walking into the same issues that slow organisations down every time a new solution arrives.

Don’t skip process mapping.
Use frameworks like MEDDIC or Value Architecture Design to ensure you’re automating a clean, well-understood workflow instead of scaling a broken one.

Don’t buy more agents than your teams can adopt.
Start small. A controlled pilot with a handful of agents will always outperform a large purchase no one is ready for.

Don’t roll out everything at once.
Introduce agents gradually so users have the space to understand how each one fits into their workflow before the next arrives.

Don’t skip process mapping.
Automating a broken process only creates a faster, more expensive version of the same problem. Map the journey first, then bring in the agent.

Don’t underestimate data quality.
Agents make decisions based on the information you give them. If your CRM, ERP or SharePoint data is inconsistent, the agent’s actions will be too.

Don’t assume governance will “figure itself out.”
Without clear ownership, shadow agents, over-permissioned tools and ambiguous access boundaries will appear quickly.

When these pitfalls are ignored, the same uncomfortable questions always come back:

“Why isn’t anyone using what we bought?”

‍“Why isn’t this delivering the value we expected?” ‍

“How did this agent end up with access to everything?”

The organisations that succeed aren’t the ones who rush. They’re the ones who pause long enough to define clean data, clear ownership, intentional design and a rollout plan that respects how humans, not machines, adapt to new ways of working.

The future of work will be humans + agents

Agent 365 is the moment Microsoft finally aligns its tools, its platform, and its vision:
every person will work through Copilot, and every system will be executed by agents.

The question for organisations now is simple:

Are you preparing for a future where digital labour is part of your workforce, or will you be retrofitting governance after the agents have already arrived?

We can help with the clarity, structure, and safe adoption you’ll need. Join our free webinar where we'll walk you through how to get AI-ready in 90 days.

‍

Soft blue and white gradient background with blurred smooth texture

Filter

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

How to Use the URL Site Map Subarea Type for View Display

Industries

Technologies

Solutions

June 21, 2024

3 min read

How to Use the URL Site Map Subarea Type for View Display

Problem Statement

We love custom views in Dynamics 365, but often face the challenge of integrating these views easily and effectively into the Site Map. Many times, we encounter the issue of only being able to specify a default view for a given table. With this solution, we can display custom views as separate menu items while maintaining user experience and clarity.

Possible Use Case

For example, if we want to track our projects by displaying ongoing and closed projects in separate menus, we can insert the URL of the views into the Site Map. Let’s go through this scenario:

Create a custom view in the Project table that filters ongoing projects. The URL for this view is::https://**********.crm4.dynamics.com/main.aspx?appid=**************&pagetype=entitylist&etn=msdyn_project&view=5ba30ec3-a0f1-ee11-904b-000d3a64fb2d&viewType=1039

Create a custom view in the Project table that filters closed projects. The URL for this view is::
- https://**********.crm4.dynamics.com/main.aspx?appid=**************&pagetype=entitylist&etn=msdyn_project&view=2ce26bab-a1f1-ee11-904b-000d3a64fb2d&viewType=1039

Default Behavior

In the Site Map, if we select the URL type and insert the view’s URL, opening it from the app will open the view in a new tab, pointing to the default table of the view, and not staying in the specified Site Map menu item.

Goal

When clicking the newly created menu item in the Site Map, it should not open the view in a new window, nor jump to the Projects menu item. Instead, it should remain in the clicked menu and display the view in the currently open window.

Solution

In the Site Map, when adding the new URL type element, do not insert the entire URL copied when opening the view. Instead, insert only the part after "dynamics.com":

/main.aspx?appid=**************&pagetype=entitylist&etn=msdyn_project&view=2ce26bab-a1f1-ee11-904b-000d3a64fb2d&viewType=1039

User Interface After Publishing the Site Map

For ongoing projects:

We see that the menu item did not switch to a new tab, and the selection remained on the chosen menu. Note that this menu item also points to the msdyn_project table, but displays the view relevant to us.

For closed projects

Additional Thoughts

It’s important to understand that this solution can be applied not only to custom views but also to other Dynamics 365 objects. Imagine how much we can integrate into the application!

Practical Tips

Remember to test the solution in different browsers and devices to ensure the application’s overall compatibility.
Use custom icons or labels for the menu items to make the Site Map even easier to navigate.

These innovations can revolutionize our work in Dynamics 365, allowing us to work more efficiently and take full advantage of the application’s capabilities! If you have any questions, feel free to contact us!

Optimization from Head to Toe: Structuring Backlogs at Visual Labs, Part Three

Industries

Technologies

Solutions

June 21, 2024

4 min read

Optimization from Head to Toe: Structuring Backlogs at Visual Labs, Part Three

In project management, administrative tasks often blend with core project activities, causing confusion and reducing efficiency. When structuring backlogs, it's essential to consider the hierarchy of administrative tasks, which helps the team better organize and manage their work. The L1, L2, and L3 levels reflect the relationship of these administrative tasks. Let's see how we can apply this hierarchy to administrative work!

‍L1 – Basic Administrative Tasks

‍The L1 level includes fundamental administrative tasks that hold strategic importance for the entire organization. These tasks are crucial for the smooth operation of the project and may encompass a wide range of activities.

‍L2 – Intermediate Administrative Activities

‍The second level, L2, includes more complex administrative activities that are more specific than L1 tasks but still exceed daily routines. This category includes internal training, pre-sales activities, HR tasks, and activities that promote teamwork and communication. L2 activities are key to the company's long-term stability but generally require more time and planning than L1 tasks.

‍L3 – Complex Administrative Projects

‍The L3 level represents the most basic administrative tasks, such as daily report preparation or handling ad-hoc tasks. These tasks are more specific within each category.Structuring administrative tasks hierarchically in the backlog helps teams better understand and manage different types of work, allowing for more efficient resource utilization and time management.

‍Beyond the Green Checkmark: Azure DevOps Statuses at Visual Labs

‍At Visual Labs, we prioritize delivering client needs efficiently and on time. We use the Azure DevOps system, which helps us manage client needs in a structured way and ensures that we track every step of the process. With Features and User Stories, we accurately record where each need is in the delivery process, ensuring transparency and efficiency for the entire team and the client.

Feature: Features handle new client needs at the client request level. They go through the following stages:

New	New client request. Not yet being worked on.
Design	We have started proposing a solution. An estimate is released during the design phase.
Awaiting Approval	Waiting for client response to approve the solution and the provided estimate/offer.
Awaiting Delivery	The client has accepted, and we have scheduled the delivery.
Under Delivery	We have started working on the request based on the submitted proposal.
Under Deployment	The feature has been delivered, and we are waiting for client validation.
Closed	The client has accepted, delivered, invoiced, or ready to be invoiced.
Removed

During the process, it was determined that the feature is not needed. It can be set to Removed status.

User Story: User Stories relate to Features and break them down into more detailed tasks. User Stories follow the same phases as Features but have slightly different interpretations and applications:

New: A new client request that has been realized and broken down into smaller units (i.e., User Stories). We know at a high level what needs to be done, but no one has started working on it yet.
Design: When we start working on the User Story description and acceptance criteria, and plan the technical requirements and delivery.
Awaiting Approval: The defined User Story is handed over to the client for approval to ensure it meets their expectations.
Awaiting Delivery: After client approval, but before actual development and work begin. All conditions are met to start working on it, but work has not started yet.
Under Delivery: The moment the development of the request begins.
Under Deployment: The completed development is waiting for release in the client environment. The User Story gets Under Deployment status when the requested functionality has been delivered on our side, handed over to the client, and we are waiting for client validation.
Closed: Once client-side validation is complete, the User Story can be closed. Ideally, this happens when the client closes the User Story, but we can also do it internally once we have received written validation.
Removed: If it turns out that the development is not needed after creating the User Story, or it cannot be implemented as previously planned. The User Story gets Removed status and a new User Story is created to continue the development request.

Using the Azure DevOps system and having clear processes and statuses ensures we manage every client need efficiently and deliver on time. This enhances client satisfaction and improves the transparency and efficiency of the delivery process at Visual Labs.

Account!T – A Small Step for Developers, a Giant Leap for Accountants

Industries

Technologies

Solutions

June 3, 2024

3 min read

Account!T – A Small Step for Developers, a Giant Leap for Accountants

“One small step for man, one giant leap for mankind” – Neil Armstrong’s iconic words from 1969 still resonate today. While comparing a moon landing to a modest extension of Business Central may seem far-fetched, this phrase came to mind as I reflected on our ERP team’s latest enhancement.

Our clients often refer to us as programmers or developers, a term we’ve grown accustomed to and usually accept with a resigned smile. But the reality is, you don’t always need large-scale developments to deliver a better, more usable product. Adding a simple field to the right screen can significantly streamline business users’ tasks, whether it’s for general ledger reconciliation, providing easier data for auditors, or shortening a user workflow by three clicks. That’s what we mean by a giant leap.

The Visual Labs ERP team has successfully implemented many Business Central projects locally. Through these projects, we’ve learned and adapted with our clients, extending the out-of-the-box Business Central product and its complementary Hungarian localization with various minor enhancements and customizations. We’ve bundled these small modifications into our own extension, making the system’s financial modules more user-friendly. We aptly named it Account!T.

In this blog post, we’ll highlight three features of our custom extension:

Notification for Failed Online Invoice Data Submission

As part of the Hungarian localization of Business Central, there's an online invoice interface that automatically submits data to the tax authority (NAV). This process is successful 99% of the time. However, there are instances where NAV rejects an invoice due to errors (like a typo in the postal code or an incorrect VAT rate). These errors are logged on the Online Invoice List page but do not generate a system notification, although legally required to submit the data.

To simplify this process and aid users, we developed an enhancement that detects online invoice submission errors. On the user's role center page, which opens at each login, we added a tile counting the erroneous online invoices. This tile turns red when there are errors needing correction, and turns green after successful data submission.

We also enabled an option to specify an email address to which the system sends a message containing a clickable link to the erroneous invoice record. This ensures the responsible user is promptly informed and can submit the corrected invoice data to the tax authority in time.

Adding the Source Name Field to the General Ledger Entries Page

Accountants regularly reconcile the general ledger and subsidiary ledgers. To improve this efficiency, we made the Source Name field available on the Business Central General Ledger Entries page. The out-of-the-box system stopped at displaying the Source Account field.

This field contains the master data identifier of the posted entry from another module (e.g., customer, vendor, bank). Previously, identifying the partner name from the subsidiary ledger required extra Excel VLOOKUP formulas. By making the Source Name field available, the associated name now appears directly by linking the underlying master data tables.

Disabling the Boxed Posting Date Validation Logic for Bank Postings

One routine task for the finance department is reconciling bank postings. Business Central includes an unavoidable posting date validation. If the bank transaction date precedes the posting date, the system blocks the posting unless the bank transaction date is modified. This discrepancy can cause reconciliation issues. For instance, an invoice covering multiple periods (like an insurance fee) might be posted with a year-end date.To resolve this, we made the boxed validation logic optional for the following documents:

Payment Reconciliation Journal
General Journal
Cash Desk

‍

These scenarios and similar ones are common for almost every Business Central user. That's why we bundled them into our custom extension, reducing unnecessary clicks and extra work, streamlining daily operations.For more details or questions, feel free to contact us. We're here to help. 😊

Optimization from Top to Bottom: How We Structure Backlogs at Visual Labs, Part 2

Industries

Technologies

Solutions

June 3, 2024

2 min read

Optimization from Top to Bottom: How We Structure Backlogs at Visual Labs, Part 2

‍

In this hierarchical model, we start with epics, representing the overall project, and break down the development cycle through various levels right up to testing. This approach helps organize work, set priorities, and track progress. Let’s dive into each element and its significance:

Epic: At the highest level, the epic represents the project itself. This category encompasses the overarching goals and the project framework. Features and user stories under the epic serve to achieve specific objectives.

Feature: Within an epic, features reflect customer needs. These are concrete requirements and expectations expressed by customers that we aim to meet throughout the project.

PBI (Product Backlog Item): These are elements of the product backlog, which can be issues or user stories.

Action: Specific activities that need to be completed to achieve the project’s goals.

Issue: Problems or bugs identified during the project, as noticed by customers.

User Story (US): Detailed breakdowns of customer requirements. These are short, simple descriptions that outline the functionalities and benefits customers expect from the product. User stories help developers understand and accurately fulfill customer needs.

Task: Specific tasks derived from user stories and features that the project team must complete.Bug: Software defects identified during development. These can be issues found by either customers or developers.
Build: Development tasks aimed at creating a new version of the software.
Test Case: Test scenarios that specify what tests need to be executed to verify different aspects of the software.
Test Plan: A comprehensive plan that includes all available test cases and their results.
The process model illustrated here covers every step of the software development cycle, from requirement gathering to testing. This aids project teams in effectively managing development activities, improving software quality, and ensuring project success. This model not only organizes needs and work but also facilitates communication with customers.
By following this structure, Visual Labs ensures that all aspects of the project are covered comprehensively, promoting efficiency and clarity throughout the development process.

Optimization from Top to Bottom: How We Structure Backlogs at Visual Labs, Part 1

Industries

Technologies

Solutions

June 3, 2024

2 min read

Optimization from Top to Bottom: How We Structure Backlogs at Visual Labs, Part 1

At Visual Labs, we leverage Azure DevOps, a powerhouse tool in software development and project management. It empowers teams to efficiently manage their work from development to release. One critical element that can significantly influence project success is the structure of the backlog. A well-organized backlog not only ensures task and requirement transparency but also helps teams set priorities, respond effectively to changes, and closely monitor project progress.

In our upcoming blog series, we will showcase the backlog structures we use, highlight the differences between them, and discuss the typical work items in these backlogs.

In this blog post, we’ll delve into how we create and efficiently manage an Azure DevOps backlog. We’ll explore practices and tips to help teams maximize their backlog’s potential. We’ll cover how to handle requirements and tasks, and how to ensure the backlog reflects the current goals and challenges of the project. Join us to discover how we enhance project management efficiency with Azure DevOps!

At Visual Labs, we distinguish between two different backlog levels:

1. Delivery Backlog:

This type of backlog contains tasks related to project or product development. It includes software development, implementing new features, bug fixes, user stories related to customer needs, and any other activities that directly impact the product or project’s output. The goal is to support the continuous development and delivery of the product or service. Tasks in this backlog typically have higher priority as they directly contribute to customer value.

2. Admin Backlog:

The admin backlog encompasses tasks related to the project’s or team’s administrative, organizational, or internal operations. This includes updating internal documentation, ensuring regulatory compliance, training team members, or any activities that are not directly linked to product or service delivery but are essential for smooth operation. While these tasks might be less urgent or critical from a product perspective, they are vital for maintaining team efficiency and seamless project execution.

Summary:

The delivery backlog focuses on product development and delivery, while the admin backlog handles internal operations and administrative activities. Both are crucial for successful project management and teamwork but concentrate on different aspects.

Industries

Technologies

Solutions

June 2, 2024

3 min read

DOJO

Background

The forum for operational development at Visual Labs is called Dojo. These sessions are held every Tuesday morning for one and a half hours. Originally launched in January 2023, Dojo was a half-day event held every two weeks and could only be attended in person.Participation in Dojo sessions is optional, although certain colleagues are often expected to attend due to their expertise. The topics of Dojo are determined by quarterly goals, and the exact agenda is set by management. These topics cover a wide range of areas, aiming to contribute to organizational development.

Why is it necessary?

Despite being a small organization, we work in distinctly defined technological areas (ERP, CRM, BI) that often serve the same clients. It is essential to have a common forum where we can gain insights into each other’s work or the company’s operations (e.g., ERP or BI colleagues are welcome at a CRM hackathon). This allows for collective thinking about how Visual Labs can develop as an organization.

Topics Covered So Far

Among others, the following topics have been discussed in Dojo sessions:

Using Azure DevOps (see: Optimization from Top to Bottom: How We Structure Backlogs at Visual Labs, Part One)
- Feature delivery process
- Managing work items
- Defining work items
- Handling statuses
Refining financial planning and billing processes
Hackathon for improving our internal CRM
Brainstorming on the development of our increasingly cramped office
Solution-seeking:
- For technical challenges
- For broadly defined, exciting client needs
Power Platform Starter Kit
- Launching the PowerPlatform Center of Excellence (CoE) Starter Kit
- Agile sprint review and planning ceremonies for the Visual Labs enhancement of the PowerPlatform Starter Kit ([[CoE+]]), where we also tested our agile wings 🙂
Customer relationship and competency training for POs, conducted by our regular coach, Klára Sugta
Knowledge sharing on the following topics:
- Customer visits
- Project launches

What Has Dojo Given Us?

Key achievements:

Creation of a Dojo Handbook that defines our main processes and operations, which we keep up to date.
Further development of the Microsoft-developed Power Platform Center of Excellence Toolkit [[CoE+]], cataloging Azure resources, DevOps projects, and areas that can be assigned to teams and users.
Strengthening and integrating the competencies outlined in the Competency Matrix into our daily routines.
Introduction of monthly financial planning with weekly tracking.
Development of our own CRM system (based on Dynamics 365 Sales and Project Operations, in collaboration with CoE+).

Other Forums for Organizational Development

Team Retrospectives
- While Dojo generally deals with cross-departmental or company-wide topics identified by management, retrospectives at the team level focus on system-level improvements in individual collaboration.
- In the future, it will be important to create a development backlog (Kaizen) to provide an overarching view of areas needing improvement, to which initiatives can be assigned and receive the necessary buy-in and resources.
1on1s
- The most straightforward opportunity to foster bottom-up ideas is through 1on1s, where topics can ripple up to management level.

The Future of Dojo

Dojo will continue to be the main forum for organizational development and will remain optional. We aim to facilitate participation in organizational development asynchronously and ensure that more written records of Dojo discussions are kept. Often, colleagues cannot attend sessions on topics they find interesting or do not find it worthwhile to sit through the entire discussion but would find a "tl;dr" version useful.If you want more information about our Dojo sessions or the topics discussed, follow our blog, as new articles on these topics are continuously published. If you have any questions or comments, don't hesitate to contact us!