But security settings are not something companies should configure once and forget. Employees change roles, partners come and go, new applications are added, permissions accumulate. It’s a moving target; administrative access that made sense during implementation might no longer be appropriate a year later.

That is why Business Central security should be reviewed periodically as part of normal system governance. As we point out in our series on Business Central permissions and security groups, too much access can increase the risk of errors or fraud, while too little access can keep employees from performing essential tasks. The objective is to give people the access they need—and only the access they need.

The most important Business Central security settings to review regularly include environment access, permission sets and SUPER users, security groups, multifactor authentication and Conditional Access, and partner or delegated administrator access.

1. Review who can access each Business Central environment

Start with the most basic question: who can access the environment at all?

Business Central online allows administrators to use Microsoft Entra security groups to control access at the environment level. When you assign a security group to an environment, only members of that group can sign in, even if other users have Business Central licenses.

That creates an important security boundary. Organizations should review whether they appropriately restrict production, sandbox, and other environments. A user who needs access to a test environment does not necessarily need access to production. Likewise, someone who still holds a license but has moved into another role may no longer need access to Business Central at all.

Security groups can also simplify ongoing administration by allowing you to manage access centrally through Microsoft Entra rather than individually in each environment.

2. Audit Business Central permission sets—especially SUPER Access

Getting into Business Central is only the first layer. The next question is what users can do after they sign in.

Business Central uses permission sets to control access to tables, pages, reports, and other application objects. Permissions can determine whether users can read, insert, modify, or delete information.

This is one of the most important areas to audit. Pay particular attention to the SUPER permission set. Microsoft defines SUPER as allowing users to read, use, update, and delete all data and application objects within the scope of their license. Business Central requires at least one SUPER user, but that does not mean many users need that level of access.

Sometimes a user or developer is given SUPER user privileges during a production emergency. The intent is to remove that access once the emergency is over, but does your organization actually verify that it happened?

Regularly review who has SUPER privileges and whether each assignment is still justified. For everyone else, follow the principle of least privilege: Users should have only the access needed to perform their jobs, without broad permissions outside their area of responsibility.

3. Use Business Central security groups instead of managing everyone individually

Permissions become difficult to manage when you configure them for each user separately.

That is one reason Microsoft and ArcherPoint recommend using security groups and permission sets together. Organizations can create groups around job responsibilities (for example, sales, purchasing, accounts payable, or warehouse operations) and assign the appropriate permission sets to those groups. Users inherit permissions based on group membership.

This approach makes it easier to manage and audit user access. When an employee changes responsibilities, administrators can add or remove that person from the appropriate security group rather than trying to remember every individual permission that needs to change.

This is a good opportunity to ask whether your current permission structure reflects how the business actually operates today. If your security model still mirrors the organization chart from implementation, it may be overdue for a review.

4. Review MFA and conditional access

Business Central online uses Microsoft Entra ID for authentication, so identity security is an essential part of its overall security. Microsoft recommends using multifactor authentication (MFA) with Business Central. MFA adds another verification factor beyond a password, making it much more difficult for an attacker to gain access with stolen credentials. For example, a company might require MFA when someone accesses Business Central or applies additional controls to higher-risk sign-ins.

Organizations with the appropriate Microsoft Entra licensing can go further by using Conditional Access. Conditional Access policies can consider factors such as the user, application, sign-in risk, and other conditions before granting access. For example, Conditional Access controls can be used to monitor and alert your security team when a user logs in after hours. (Is there a reason someone is accessing the General Ledger late on a Saturday night?)

This matters because compromised credentials remain one of the easiest ways attackers gain access to business systems. At a minimum, your company should verify that MFA is being enforced appropriately and review whether Conditional Access policies still match your security requirements.

5. Review partner and delegated administrator access

Many Business Central customers rely on Microsoft partners for implementation, support, upgrades, or administration. That access should be reviewed just as carefully as internal access.

Business Central allows organizations to control partner access at the environment level. Internal administrators can allow or block delegated administrator access and can restrict access to specific partner Microsoft Entra tenants. Microsoft notes that environments can otherwise be configured to allow all partner access associated with existing tenant-level relationships.

That makes periodic review important. Ask which partners currently have delegated administrative access, whether those relationships are still active, and whether each partner needs access to every environment.

Old implementation partners, former consultants, or third-party applications should not retain access indefinitely simply because no one remembered to remove it.

Is your Business Central security still right for your business?

Business Central provides a strong security framework, but its effectiveness depends on how you configure and maintain it. A useful security review doesn’t have to start with a massive audit. Start with five questions:

• Who can access each environment?
• Who has elevated permissions?
• Are permissions managed through well-defined security groups?
• Is identity protection, such as MFA, properly configured?
• And who outside the organization still has administrative access?

Business Central security is not a one-time implementation task. It should evolve as employees, partners, business processes, and risks change.

Periodic reviews of these settings can reduce unnecessary access, simplify administration, and strengthen internal controls.

Contact ArcherPoint by Cherry Bekaert with any questions or concerns about your Business Central security. ArcherPoint provides managed IT services, including remote monitoring, security audits, data security, data backup and disaster recovery, and more.

The post 5 Business Central Security Settings Every Company Should Review appeared first on ArcherPoint.

That view is increasingly outdated.

A cyber incident can affect far more than systems and data. It can interrupt operations, delay shipments, expose sensitive information, disrupt suppliers, create regulatory problems, damage customer confidence, and generate significant financial losses. IBM’s 2026 Cost of a Data Breach Report put the global average cost of a data breach at $4.99 million, driven in part by higher detection, escalation, and lost-business costs.

From the report: “Two cost categories—detection and escalation and lost business—made up the majority (63%) of costs in this year’s report. Those costs include everything from crisis management to disrupted operations and customer churn.”

Cybersecurity risk is business risk because a cyber incident can affect an organization’s revenue, operations, supply chain, regulatory obligations, customer relationships, and ability to continue operating—not simply its technology.

For business leaders, cybersecurity therefore belongs in the same conversation as financial risk, operational resilience, supply chain continuity, compliance, and governance.

Cybersecurity risk is financial risk

The financial consequences of a cyberattack extend well beyond the cost of repairing systems.

Organizations may face business interruption, lost revenue, forensic and legal expenses, customer notification costs, regulatory penalties, increased insurance costs, and the expense of restoring compromised environments. A serious incident can also redirect employees and leadership away from revenue-generating work for days or weeks.

That makes cybersecurity a risk-management investment, not simply an IT expense. Executives do not need to understand every technical control, but they should understand questions such as:

• What systems are most critical to revenue and operations?
• How long could the company function without them?
• What would a day of downtime cost?
• Which information would create the greatest exposure if it were stolen or unavailable?

Cybersecurity and business continuity: Operational disruption can be the bigger threat

Not every cyberattack is primarily about stealing data. Sometimes the most damaging outcome is losing access to the systems the business depends on.

If employees cannot access ERP, CRM, email, production systems, warehouse applications, or financial data, normal operations can quickly slow or stop. Orders might not ship. Invoices might not go out. Plants might lose visibility into production. Customer service teams might be unable to answer basic questions.

That is why cybersecurity and business continuity increasingly overlap. Organizations need not only controls designed to prevent attacks, but also the ability to detect incidents quickly, contain them, recover systems, and continue operating.

Supply chain cybersecurity extends risk beyond your business

Cybersecurity risk does not stop at the company firewall. Manufacturers and distributors increasingly depend on interconnected suppliers, logistics providers, software vendors, cloud platforms, contractors, and customers. Every connection can introduce another dependency and another potential vulnerability.

The National Institute of Standards and Technology (NIST) specifically treats cybersecurity supply chain risk management as an enterprise risk discipline, emphasizing the need to identify, assess, and mitigate risks associated with suppliers, technology products, and services throughout their lifecycle.

A single supplier with weak security can create operational risk for everyone connected to it. That means vendor selection should increasingly include questions about cybersecurity posture, access controls, data handling, incident response, and resilience.

How cybersecurity risk affects customer trust

Customers provide businesses with a significant amount of information: contact details, purchase history, pricing, financial data, account credentials, intellectual property, and other sensitive information.

They expect that information to be protected. A breach can therefore become a trust problem as quickly as it becomes a technology problem. IBM notes that data breaches can contribute to reputational damage, erosion of customer trust, and customer churn, in addition to direct financial and regulatory costs.

The same principle applies in B2B relationships. Customers increasingly want assurance that suppliers have appropriate cybersecurity controls before integrating systems or sharing sensitive information.

Strong cybersecurity is increasingly part of an organization’s value proposition—not because customers necessarily want to discuss security technology, but because they want confidence that their business will not be put at unnecessary risk.

Cybersecurity, compliance, and data governance are becoming more interconnected

Businesses also operate under a growing set of privacy, security, and data governance requirements.

The exact obligations vary by industry, geography, and the type of information an organization holds, but the underlying challenge is the same: Businesses need to understand what sensitive information they have, where it resides, who can access it, and how it is used.

Compliance does not guarantee security, and security does not automatically guarantee compliance. But both depend heavily on visibility, governance, and data control.

Identity security is a critical cybersecurity boundary

Many modern attacks do not begin with someone “breaking into” a network. They begin with a compromised identity.

A stolen password, a successful phishing attempt, or an overly privileged account can provide an attacker with access that appears legitimate.

For businesses, the principle is straightforward: Access to critical business systems should be based on who someone is, what they need, and the level of risk involved—not simply whether they know a password.

Cybersecurity risk management is a leadership responsibility

IT and security teams will continue to own much of the technology behind cybersecurity. But they cannot own the business risk alone.

Leadership must determine which operations and data matter most, define acceptable risk levels, fund appropriate controls, establish governance, evaluate third-party risk, and ensure the organization can respond when something goes wrong.

The most useful question might therefore be less technical: If one of our critical systems were unavailable tomorrow, how well could we continue operating? The answer says a great deal about both cybersecurity and business resilience.

But technology is only part of the equation.

Cybersecurity becomes much more effective when the organization stops treating it as an IT project and starts managing it as a business risk. That same business-wide approach should extend to the systems that hold and process some of the organization’s most critical information—including its ERP.

Make Business Central part of your broader security strategy

Your ERP contains some of your organization’s most important financial, customer, operational, and business data. Protecting it requires more than passwords and permissions—it requires an approach that connects identity, access, data governance, threat protection, and business resilience.

Business Central operates within the broader Microsoft cloud ecosystem, allowing organizations to incorporate ERP into a larger approach to identity, access, data governance, security, and compliance. Microsoft Entra provides identity and access management capabilities, while Microsoft’s broader security and compliance technologies can help organizations protect identities, data, applications, and cloud environments.

To learn more about protecting your company from cybersecurity threats, download our free eBook, Cybersecurity Threats & Countermeasures: Protecting your company from external and internal threats.

To learn how you can strengthen Business Central security, read our blog series, Managing Permissions and Security Groups in Dynamics 365 Business Central.

Contact ArcherPoint by Cherry Bekaert to learn how we can help you evaluate your Business Central environment, strengthen access and security practices, and make ERP security an integrated part of your company’s cybersecurity strategy.

The post Cybersecurity Risk Isn’t Just an IT Issue—It’s a Business Risk appeared first on ArcherPoint.

You can catch up on these blogs here:

• Managing Permissions and Security Groups in Dynamics 365 Business Central – Part I: Permission Sets
• Managing Permissions and Security Groups in Dynamics 365 Business Central – Part II: Security Groups
• Managing Permissions and Security Groups in Dynamics 365 Business Central – Part III: Managing Licensing and Effective Permissions

The takeaway from these blogs is that, whenever possible, it’s better to control user access by adjusting security groups and permission sets rather than defining permissions directly on the user card. This makes it much easier to determine who in the organization can access specific tasks: Whoever is in that security group has access to whatever that security group is allowed to access.

The goal is to tighten permissions when it makes sense to protect business data while still giving everyone enough freedom to do their job.

In this blog, we continue the discussion by covering recording permissions, auditing, and troubleshooting tips.

How Permission Recording works in Business Central

Recording permissions is best used only occasionally for troubleshooting because it captures a wide range of items, including non-sensitive table data like buffer and setup tables, making it hard to determine the specific access the user needs.

The best use of permission recording is to capture when a user tries to perform a task and can’t because of a permission issue. The user might or might not receive a helpful error message when the problem occurs. If they don’t receive a useful error message, Permission Recording can help identify where the error occurs and allow the administrator to identify and give the user the permissions they need to do their job.

A word of caution: If you record permissions for each task a user performs and create a permission set for each task, you might end up granting permissions in a cross-functional way you didn’t intend. Be sure to follow the principle of least privilege.

How to Record Permissions in Business Central

The steps to record permissions are:

1. Identify the business role/process
2. Create a new Permission Set
3. Name the Permission Set
4. Open the Permissions page
5. Start recording the permissions: Select Actions > Record Permissions > Start
6. Perform the business process as the user would normally perform it
7. Stop the Recording
8. Review the recorded permissions. Look for permissions that grant the user Read, Insert, Modify, Delete, and Execute

Step 1: Identify the business role/process

This comes from the user’s business needs. Typically, the user will say they are prevented from performing an essential task, like setting up a new customer, creating an invoice, or creating a purchase order. They may or may not receive an error message. Recording permissions is a good way to identify missing permissions and grant the user the appropriate access, especially when the error message provides little to no information.

In this example, we will be creating a sales order. This task is typically straightforward: Create the sales order, populate it with the customer information and the item(s) they want to purchase, then release the sales order.

Step 2: Create a new Permission Set

From Permission Sets, select New to create a new Permission Set (Figure 1).

Step 3 – Name the Permission Set

Give the new Permission Set a descriptive name. Notice that its Type is set to User-Defined rather than System (Figure 2).

Step 4 – Open the Permissions page

When you open the new Permissions page (Figure 3)…

…it will be blank (Figure 4) because you have not added permissions yet.

Step 5 – Start recording the permissions

Start recording the permissions: Select Actions > Record Permissions > Start (Figure 5). Once the recording starts, leave the screen open.

Step 6 – Perform the business process as the user would normally perform it

In this example, we are creating a new sales order. So, in a separate window, navigate to Sales Orders and create a new sales order (Figure 6).

Once created, populate the new sales order with data, then release it (Figure 7).

Step 7 – Stop the Recording

Stop Recording Permissions. Go to Permission Set > Actions > Record Permissions > Stop (Figure 8).

You will be asked if you want to add the recorded permissions. Select “Yes” to add the recorded permissions and view them (Figure 9).

Step 8 – Review the recorded permissions

Review the recorded permissions (Figure 10). Look for permissions that grant the user Read, Insert, Modify, Delete, and Execute.

Review the permissions from the recording.

You will notice there is a column showing various Object Types: Codeunit, Page, Query, Table, and Table Data. There are also columns for different permission types: Read, Insert, Modify, Delete, and Execute.

Pay close attention to the Table Data rows. The goal is to limit the user’s access to Table Data as much as possible, especially the ability to Insert, Modify, and Delete data. You are primarily concerned about the user’s access to Table Data because even if a user can open a Table, they can’t view the Table Data. Instead, they will see a blank table.

Many users find it more convenient to export the data to Excel for analysis (Figure 11).

Excel makes it easier to sort permissions by Object Type (Figure 12). Often, the problem stems from the user not having sufficient permissions to access Table Data. Sort by Table Data to find any missing permissions.

You can use AI to help you locate missing permissions by comparing your recording to the user’s permission set (Read, Modify, etc.).

A word of caution: Always use AI wisely! Many AI platforms require you to specifically request that your data not be shared for public AI model training. To limit public access to your data, configure your profile settings to control who can see it.

Use permission recording sparingly, mostly for troubleshooting. To illustrate the point, simply creating a new sales order in this example generated over 340 different items the user needs permission to access – most of which are not important (Figure 13).

TIP: You can review the BI report and find out where permissions were granted. If you need to adjust, adjust the appropriate security group based on what you find. But don’t just mindlessly use this permission set and give it to the user. The goal is not to give permissions to a user, but to give permissions to a security group.

Troubleshooting Business Central user permissions with Effective Permissions

Recording permissions is just one way to troubleshoot permission issues. Another technique is to investigate the user’s effective permissions for greater insights. To review effective permissions, see Effective Permissions in Managing Permissions and Security Groups in Dynamics 365 Business Central – Part III: Managing Licensing and Effective Permissions.

Run the Effective Permissions request from the User Card (Figure 14). It might take a while to complete, but it provides a comprehensive list of a user’s effective permissions. Since it’s not easy to see what’s going on in that list, use it as a troubleshooting tool. You can also export the list to Excel or create a Power BI report to make it easier to search the information.

Suppose a user made a change they shouldn’t have permission to make. This tool can trace the issue to a specific user and the problematic permission. Take the permission from the Power BI report, determine which permission sets and/or security groups grant access to the table in question, and isolate the problem.

The Effective Permissions tool can help you determine where the permission is and where it’s assigned from. From there, you can review where those permissions should be assigned and whether they are in the correct place. You can now check and decide where you want that permission to reside.

The Effective Permissions results (see Figure 15) show a column labeled User-Defined Permission Set. User-Defined Permissions have a checked checkbox. Those without a checked box come from a standard permission set from Microsoft. As stated in earlier blogs, standard permission sets can be too lenient when it comes to reducing user access. Since Microsoft can update these permission sets at any time, use User-Defined permission sets whenever possible.

Auditing Business Central permissions and changes

Business Central includes a comprehensive set of native auditing capabilities.

For example, the Change Log records what changed, who changed it, and when. Once you specify the tables and fields you want to log, activating the Change Log will track all direct modifications made to the database. You can also use the Data Analysis feature to analyze Change Log data.

NOTE: Using the Change Log can affect system performance.

In addition, the Financial Report Audit Log lets you track user activities related to financials for auditing purposes.

Using Power BI to analyze permissions and Change Log data

You can also use Power BI to build additional reports to help audit user permissions and permission sets. For instance, you can build a Power BI report (Figure 16) showing which permission sets allow access to various areas of Business Central, such as table data, tables, pages, etc.

Ultimately, your focus is mainly on table data because that is what we are trying to lock down for limited access.

A Power BI report showing permissions by permission set can help determine who can change sensitive company data. For instance, Figure 17 shows an example where the Purchase Doc permission set allows the user to modify payment terms. Since typically only the account manager should have this access, not the daily user, the administrator should remove it from the permission set.

Power BI reports can also be linked to the Change Log to show when changes are made to critical data. For example, Figure 18 shows that Admin deleted table data. The report includes not just the user name, but also the time, date, type of change, table number, and field number.

As another example, Figure 19 shows that Admin changed a customer’s credit limit from $5,000 to $2,000.

As these Power BI reports show, the Change Log can be used to find database changes by specific tables, specific users, or other criteria, and it can be a powerful tool for internal and external auditors.

NOTE: Run the Change Log only on a limited number of fields to minimize clutter and reduce system performance impact.

How to set up the Change Log in Business Central

To use the Change Log, you must first activate it (Figure 20).

After you activate the Change Log, select the tables and fields you want to monitor. Selecting All Fields (Figure 21) logs every action on the table, which makes the log data difficult to read.

Instead, choose Some Fields (Figure 22)…

…which lets you select the specific fields you want to track in each table (Figure 23).

Each company must determine which tables, fields, and actions to track, particularly when required by government regulations, accounting audits, or other oversight groups.

Figure 24 shows an example of a Change Log set up to track specific tables, fields, and actions for auditing purposes.

Do the right people have the right access?

Business Central permissions can become increasingly complex as users, roles, security groups, and business requirements change. Too much access can put sensitive data at risk, while overly restrictive permissions can prevent employees from doing their jobs.

You don’t have to do this alone!

Contact ArcherPoint by Cherry Bekaert and let us help you evaluate your Business Central security model, identify permission gaps and unnecessary access, and establish a more manageable approach to user roles, security groups, auditing, and ongoing permission management.

The post Managing Permissions and Security Groups in Dynamics 365 Business Central – Part IV: Permission Recording, Auditing, and Troubleshooting appeared first on ArcherPoint.

Three days later, Anthropic published a research report that measured many of the same behaviors across nearly 10,000 real conversations.

My first reaction was not validation. It was curiosity. I have been preaching literacy before agency for months, so I wanted to know what this study revealed about fluency, and how it overlapped or challenged what I had been saying. But as I read deeper, what excited me most was not the findings themselves. It was the idea that fluency could be measured. I had spent 34 weeks advocating for AI literacy without ever thinking seriously about how you would know if someone had it. What would improvement look like? How would you track it? And more importantly, could you build a system that actively coached you toward it?

Within a few hours of finishing the report, I had built exactly that. But I am getting ahead of myself.

What the 4D AI Fluency Framework measures

The study is built on the 4D AI Fluency Framework, developed by professors Rick Dakan (Ringling College of Art and Design) and Joseph Feller (University College Cork) in collaboration with Anthropic. It defines four core competencies for effective human-AI collaboration.

Delegation is deciding whether, when, and how to engage AI. Description is communicating effectively with AI. Discernment is critically evaluating AI outputs. Diligence is taking responsibility for what you do with AI.

Each competency breaks down into subcategories, 12 specific behaviors in total. The researchers used Anthropic’s privacy-preserving analysis tool to study which of these behaviors appeared in 9,830 Claude conversations during a one-week window in January 2026.

Here is the critical limitation: they could only observe half of the behaviors, the ones that happen inside the chat window. The ones that cannot be observed inside the chat window, including things like being honest about AI’s role in your work and considering the consequences of sharing AI-generated output, happen after you close the conversation. Those are arguably the most consequential dimensions of fluency, and they are invisible to any platform that is watching.

I will come back to that gap. It matters more than the findings themselves.

Three AI fluency findings every business leader should know

Finding 1: Iteration is everything, and most people are not doing it.

The single strongest predictor of every other fluency behavior was iteration and refinement, treating AI’s first response as a starting point rather than a final answer. Conversations that included iteration showed roughly double the rate of all other fluency behaviors. They were 5.6 times more likely to involve users questioning AI’s reasoning, and 4 times more likely to see users identifying missing context.

Last week I called iterative refinement “the most important unnamed skill in the entire series.” I had been demonstrating it in every article for 33 weeks without once calling it out as something to learn. Now there is data showing it is the single strongest correlate of AI fluency across nearly 10,000 conversations. Not just important. Foundational.

If you are using AI and accepting the first response, you are not collaborating. You are placing an order.

Finding 2: The better AI looks, the less people think.

This is the finding that should genuinely give leaders pause. When AI produces polished artifacts, code, documents, interactive tools, things that look finished, users become more directive upfront but less critical of what comes back. They are less likely to question the reasoning, less likely to check facts, less likely to identify what is missing.

Read that again. The more competent the output appears, the more people let their guard down.

But I think the research is pointing at something deeper than people failing to review polished output. The real issue predates AI entirely: confirmation bias.

We have always done just enough research to justify our point of view. The difference is that without AI, I had an external gauge of how seriously I had challenged my own assumptions. If I spent no time researching, I could not pretend to have overcome my own preferences. If I spent hours digging through sources, I could at least make a case that I had tried. The effort itself was a signal, imperfect, but visible.

AI eliminates that signal. It produces well-formed, authoritative-looking output almost instantaneously. I can review it carefully, confirm that AI agrees with me, and present it as if it were the product of hours of painstaking research, because I have no external gauge of whether AI is telling me what I want to hear or whether the analysis is truly objective. And it is just amazing how often AI confirms what I believed all along.

This is the abdication problem I have been writing about, now measured. It is not that AI produces bad output. It is that AI produces output that looks good enough to stop thinking, and that feels like independent validation of conclusions you had already reached.

Finding 3: 70% of people never set the terms of the collaboration.

Only 30% of users in the study told Claude how they wanted it to interact with them. Things like “push back if my assumptions are wrong” or “walk me through your reasoning before giving me the answer” or “tell me what you’re uncertain about.”

Seventy percent of people are showing up to a collaboration without establishing how the collaboration should work. That is like hiring a consultant and never telling them what you actually need, then being disappointed when they give you something generic.

Week 34 Skill 1 was “Set the Stage,” everything before AI’s first response. Context, roles, constraints, format. The research says most people skip all of it.

How the 4Ds compare to the four AI skills framework

Here is where it gets interesting, and where I want to be honest about what this research revealed about my own blind spots.

The 4D Framework breaks AI fluency into Delegation, Description, Discernment, and Diligence. Last week I broke my skills into Set the Stage, Read It Like a Skeptic, Work the Conversation, and Think Bigger / Think Better. The overlap is significant but not perfect, and the gaps are revealing.

My “Set the Stage” maps roughly to their Description, how you communicate with AI. My “Read It Like a Skeptic” is their Discernment, critically evaluating what comes back. My “Work the Conversation,” iteration, context management, knowing when to start over, is what their research showed as the single most important behavior.

But their framework has two areas where my self-taught approach has gaps.

Delegation, the decision about whether to use AI at all, and which modality to use, is something I have mostly learned by instinct rather than by design. I have written about automation versus augmentation, about the progression from literacy to agency. But the deliberate, conscious choice of “should AI be involved in this task, and if so, how?” is a muscle I developed by trial and error, not by intention. The framework names it as a discrete competency. I treated it as obvious. It is not obvious to someone just starting.

Diligence, taking responsibility for AI-assisted work, is the one that hits hardest. Not because I have been irresponsible, but because this is the competency that matters most for organizational transformation and it is almost entirely invisible to measurement. Anthropic could not observe half of the behaviors because those behaviors happen after the conversation ends: verifying before publishing, being transparent about AI involvement, considering stakeholder impact, maintaining ethical standards.

Those invisible behaviors? That is where organizational AI transformation lives or dies. And it is exactly the territory I am moving into as this series shifts from personal literacy to leadership.

Building an AI fluency coaching system from research

Most people will read that research report, nod thoughtfully, and change nothing. I know this because I have watched it happen with every AI insight I have shared over 34 weeks. Reading about fluency does not build fluency. So I decided to build something.

The question was simple: could I take the 4D Framework and embed it directly into my AI project instructions, not as a reference document, but as an active coaching system? Instead of just knowing what fluency looks like, could I get AI to flag when I was falling short in real time?

I used the research itself as my starting point and collaborated with AI to design the system. The first design decision was what not to do. A static self-rating, “I’m a 3 out of 5 on Discernment,” would go stale immediately. Instead, we designed behavioral triggers mapped to each of the 4Ds. Specific patterns that, when AI observed them in our actual work, would prompt a coaching intervention.

For Delegation gaps: if I ask AI to make a judgment call that benefits from my domain expertise, it pushes back and asks for my instinct first. If I am doing something manually that is a strong candidate for AI augmentation, it flags the missed opportunity.

For Description gaps: if my prompt is vague when the task demands precision, it asks for specifics rather than guessing my intent. If I am not providing enough context for quality output, it tells me what is missing rather than working around it.

For Discernment gaps: if I accept a complex output without questioning it, it flags the weak point and asks if I want to stress-test it. If I am treating AI output as authoritative in areas that require verification, it names the risk.

For Diligence gaps: if I am preparing to share AI-assisted work without discussing verification, it asks about my review process. If I am not considering stakeholder impact or transparency, it raises what I am missing.

The hardest design problem was timing. When I first tested the concept, I realized that AI would read the fluency instructions and immediately start coaching, before it had any signal to coach on. Getting a Discernment nudge on your opening message would be insufferable. So we added a calibration rule: fluency coaching is observational, not preemptive. Never coach in the first response. Wait for actual behavioral evidence. And if the conversation pace indicates rapid task execution, those moments when you are just trying to get something done quickly, hold observations for a natural pause rather than interrupting flow.

That calibration detail is small, but it is the kind of thing you only figure out by building and testing. The research can tell you that iteration matters. It cannot tell you that your coaching system needs a timing delay to avoid becoming noise.

I have since embedded these instructions across my active projects. It is early, but I am already noticing something: just knowing the coaching system is there changes my behavior. I catch myself being more specific in my prompts because I know vagueness will get flagged. I pause before accepting polished output because I know the Discernment trigger is watching. The measurement itself is changing what it measures.

AI literacy vs. AI fluency: what’s the difference

There is a language choice in this research worth addressing. I have been using “literacy” throughout this series. Dakan and Feller chose “fluency.” Those are not synonyms, and the distinction matters.

Literacy is foundational understanding, can you read the language? Fluency is comfortable, natural application, can you think in the language? What I have been documenting over 34 weeks is actually the progression from one to the other. Early weeks were literacy: understanding what AI is, how it works, where it breaks. Later weeks, building solutions, diagnosing organizational problems, designing workshops, embedding coaching systems into project instructions, that is fluency.

The distinction matters because most organizations are trying to achieve fluency while skipping literacy. They want their teams to think naturally with AI without first ensuring those teams understand what AI actually is. The research shows what that looks like in practice: people who are directive but not evaluative, who specify what they want but do not question what they get. That is not fluency. That is ordering confidently from a menu in a language you do not speak.

What this means for AI governance and adoption

If you are responsible for an organization’s AI adoption, this research gives you three actionable insights.

First, stop measuring adoption and start measuring fluency. How many people have AI accounts is meaningless. How many are iterating, questioning, setting collaboration terms, that tells you whether your investment is producing capability or just consumption.

Second, the biggest risk is not AI failure, it is AI success. The finding that polished outputs reduce critical thinking should reshape how you think about AI governance. Your team will not get burned by obviously bad AI output. They will get burned by output that looks professional, reads well, and is subtly wrong in ways that matter. Especially when it confirms what they already believed.

Third, the invisible behaviors are your responsibility to build. Anthropic cannot measure whether your team is being transparent about AI use, verifying before publishing, or considering stakeholder impact. No platform can. Those are organizational culture decisions, and they require leadership that has experienced the full journey from literacy to fluency, not leadership that skipped to the end.

Your Week 35 challenge: run your own fluency audit

1. Score yourself against the 4Ds. Delegation: Are you making conscious decisions about when to use AI and which modality to use? Description: Are you setting context, specifying format, providing examples? Discernment: Are you questioning AI’s output, catching errors, evaluating whether the collaboration is working? Diligence: Are you verifying before sharing, being transparent about AI involvement, considering stakeholder impact? Be honest about where you are strong and where you are coasting.
2. Check your iteration habit. Look at your last five AI conversations. How many times did you accept the first response and move on? How many times did you push back, refine, redirect? If you are mostly accepting first drafts, you are leaving the most important fluency behavior on the table.
3. Set the terms once. In your next AI conversation, start by telling it how you want the collaboration to work. “Push back on my assumptions. Tell me what you’re uncertain about. Don’t just agree with me.” See how the conversation changes. You are joining the 30% who actually do this.
4. Examine your Diligence. The next time you are about to share, publish, or act on AI-assisted work, pause. What is your verification process? Who knows AI was involved? What is your accountability if something is wrong? These questions do not happen inside the chat window. They happen inside you.

The bottom line

Thirty-four weeks of documenting my own AI transformation, and a research team just published data validating the core patterns I discovered through trial and error. Iteration matters most. Polished outputs are the most dangerous, especially when they confirm what you already believed. Most people never set the terms of the collaboration. And the behaviors that matter most for organizations cannot be measured by any platform, they require human judgment, human accountability, and human leadership.

But validation is not the point. Action is. Within hours of reading this research, I had built a coaching system that uses the 4D Framework to actively improve my own fluency in every AI conversation. Not because reading the research made me fluent. Because 34 weeks of building things taught me that the distance between insight and capability is always the same: you have to do something with what you learn.

I have been calling this “literacy before agency.” The academic framework calls it developing fluency across Delegation, Description, Discernment, and Diligence. The vocabulary is different. The destination is the same: you have to do the work yourself before you can lead others through it.

Nobody develops AI fluency by reading a research report. Just like nobody developed it by reading this series. You develop it by opening a conversation, setting the terms, doing the work, questioning the output, and showing up again tomorrow.

Thirty-five weeks in, I am still showing up. The research just confirmed why it is working.

Sources referenced:

• Swanson, K., Bent, D., Ludwig, Z., Dakan, R., & Feller, J. (2026). “Anthropic Education Report: The AI Fluency Index.” Anthropic, February 23, 2026.
• Dakan, R. & Feller, J. “The 4D Framework for AI Fluency.” AI Fluency: Framework & Foundation.” Anthropic Academy. Framework documentation.

This post is part of my “AI Over 40” series. It first appeared on LinkedIn: Where AI Literacy Meets AI Fluency

Read more AI and Copilot blogs.

The post AI for the Over 40: Week 35 – Where AI Literacy Meets AI Fluency appeared first on ArcherPoint.

Overcoming disconnected retail operations

Shrinkage is often a symptom of a larger issue: a lack of clear, connected operational data. When storefronts, warehouses, and eCommerce platforms operate in silos, finding the source of lost revenue becomes nearly impossible. Unifying your systems is the first step toward robust profit protection.

Identifying the sources of shrinkage

Modern retail shrinkage extends far beyond traditional shoplifting. Some internal vulnerabilities can include administrative errors at receiving, pricing mistakes at the register, and vendor discrepancies. Additionally, paper-based tracking or legacy spreadsheets can create operational blind spots where these costly errors go unnoticed. 

Achieving total operational visibility

The primary way to reduce inventory shrinkage is to gain an accurate picture of daily store operations. Disconnected systems often leave management in the dark, turning end-of-quarter inventory counts into stressful, reactive events.

With total visibility, managers can watch a single item move seamlessly from the warehouse to the store shelf and through the checkout line. This level of transparency strengthens teams to spot and correct discrepancies the moment they occur.

Shifting to proactive profit preservation

Moving away from a reactive mindset allows you to stop losses before they happen. A modern ERP acts as the central nervous system of your business, turning passive data into an active defense strategy that preserves your bottom line.

The advantage of a unified system

Using a retail ERP to reduce shrinkage transforms a reactive defense into a proactive strategy. Additionally, unifying Point of Sale (POS), workforce management, and supply chain data into a single platform can reduce communication barriers. This approach aligns loss prevention teams and store operations around the same dataset, saving time and resources.

Automating your defense strategy

Modern software replaces guesswork with intelligent, automated workflows. For example, the system can trigger an immediate alert to a manager if a single cashier processes an unusually high volume of no-receipt returns during a single shift. Automating these alerts frees up store leaders to focus on customer service and team coaching rather than playing detective.

Empowering your workforce with better tools

Implementing a secure ERP can reduce the burden on your store associates of policing. Automated loss prevention systems allow your staff to focus entirely on customer service and building relationships, rather than stressing over inventory discrepancies. In addition, clear POS permissions and automated counting can help boost employee morale by providing clear expectations and intuitive digital tools.

Configuring your ERP to safeguard profits

The true power of an ERP lies in its tactical configuration. By setting up specific, automated rules and permissions, you can create a secure environment that protects your inventory while empowering your staff to operate efficiently. 

Here’s a closer look at how this works:

• Automating POS permissions for accountability: Limiting critical POS functions such as voids, negative adjustments, and cash refunds to manager-only access via a secure PIN or swipe card implements positive protections. It prevents entry-level staff from making accidental, costly administrative errors and can create a traceable audit trail for all high-risk transactions.
• Implementing real-time transaction monitoring: Retail transaction monitoring actively syncs sales data with inventory levels to flag pricing anomalies instantly. This data acts as a constant pulse check for your store’s health. Leadership can use these insights to identify specific training opportunities for staff, such as targeted coaching after noticing the store has higher-than-average discount overrides.
• Streamlining accuracy with cycle counting: Cycle counting is a positive, tech-driven alternative to exhausting, store-closing annual audits. The ERP intelligently suggests which aisles or product categories to count based on recent sales volume or discrepancy history. ERP-guided cycle counts keep the store open, generate revenue, and maintain pinpoint shelf accuracy year-round.
• Customizing dashboards for executive oversight: An ERP translates millions of data points into easy-to-read executive dashboards. Regional managers can open their dashboard each morning to view a color-coded snapshot of shrink risks, top-performing stores, and inventory health across store locations. This high-level visibility allows leadership to make confident, data-backed decisions quickly rather than waiting for monthly reports.

Securing your supply chain and receiving operations

Profit preservation starts long before a product ever reaches the sales floor. If your receiving dock is operating on manual paper trails, you are vulnerable to vendor discrepancies and invoice fraud. A modern ERP extends your security perimeter all the way to your supply chain.

The ERP automates a three-way match, comparing the purchase order, the receiving report, and the vendor invoice. This system instantly flags discrepancies if a vendor short-ships an order or inflates an invoice, so you only pay for what you receive.

Additionally, warehouse staff can use mobile ERP scanners to digitally intake inventory into the system upon arrival. These tools are helpful for your employees, as they reduce the stress of manual paperwork and the chance of administrative entry errors.

Creating a secure omnichannel experience

Your customers expect a seamless shopping experience, whether they are buying your products online or in-store. A unified ERP ensures that delivering this experience keeps your business safe from complex cross-channel inventory discrepancies or return fraud.

Establishing a single source of truth

Omnichannel retail can bring unique risks, such as double-selling items or mismanaging stock across different geographical locations. A centralized ERP deducts online sales from physical store inventory to provide accurate stock levels. Accurate data then prevents the frustration of a customer buying an item online that was just sold in-store, protecting your brand reputation.

Protecting the return process

Cross-channel return fraud can be challenging, particularly the tactic of returning a stolen or online-purchased item in-store without a valid receipt. Leveraging your ERP for fraud detection enables the system to cross-reference the item, the customer profile, and the digital receipt across all store locations. This validation can reduce fraudulent return rings while keeping the process fast and frictionless for honest customers.

Maximize profitability with ArcherPoint

Technology is only as effective as its implementation. Partnering with seasoned experts ensures your POS and ERP systems are configured to protect your revenue and support your growth.

ArcherPoint is a specialized retail technology expert dedicated to profit preservation. We have deep knowledge in configuring Microsoft Dynamics 365 and LS Central for secure, and user-friendly retail environments. Our team goes beyond off-the-shelf software, tailoring these powerful tools to fit the unique operational footprint and workflows of your business.

We are your long-term partner, committed to comprehensive team training and ensuring your staff feels completely confident using the new system from day one. As your retail business grows, ArcherPoint can provide the ongoing technical support needed to scale your loss prevention architecture seamlessly.

Take control of your margins with our solutions today

Professional implementation is the key to turning software features into actual margin protection and business growth. Contact the ArcherPoint team to schedule a system evaluation. Our collaborative assessment can help identify current vulnerabilities and map a secure, customized tech architecture.

Frequently asked questions about retail demand planning

Take a look at some of the most commonly asked questions we receive about the application of ERP in retail.

What is the difference between demand planning and inventory management?

Inventory management tracks what you currently have on hand, while demand planning uses historical and real-time data to predict what you will need in the future.

How long does it take to see results from AI forecasting?

While AI models continuously learn and improve over time, retailers can generally see a reduction in stockouts and overstocking within the first few ordering cycles after an ERP upgrade.

How does demand planning handle sudden supply chain disruptions or vendor delays?

A modern ERP constantly tracks variable vendor lead times and allows you to dynamically adjust your safety stock thresholds. It gives you the agility and confidence to navigate unpredictable shipping delays without letting your customers down.

Unifying your retail ecosystem with ArcherPoint

Migrating to a unified, modern commerce solution like Microsoft Dynamics 365 Business Central and LS Central provides immense value for your retail company. With ArcherPoint, our decades of retail expertise in custom-configuring closed-loop ecosystems can help you seamlessly connect POS, financials, and warehouse management. This upgrade is more than new software — it’s a strategic partnership designed to put inventory restocking on autopilot so the business can thrive.

Ready to get started? Contact the ArcherPoint team to discuss upgrading your retail management systems to support your next phase of growth.

The post Loss Prevention in the Digital Age: How to Use Your ERP to Reduce Retail Shrinkage and Prevent Fraud appeared first on ArcherPoint.

The Dynamics 365 Business Central community, consisting of developers, project managers, and consultants, collaborates across various platforms to share valuable insights. At ArcherPoint, we greatly value their dedication and expertise. To ensure widespread access to this technical knowledge, we created Developer Digest.

Controlling a race condition when using IsolatedStorage

Before runtime version 18.0, you could encounter a race condition when using the IsolatedStorage object, where two sessions could retrieve the same key, compute different values, and then one session could overwrite the other.

Beginning with 18.0, the IsolatedStorage.Get method accepts an optional parameter, UpdLock, to control how the underlying key is locked when being read. This prevents any other session from reading or writing the same key until the transaction completes.

Important: Using this parameter to update the lock can cause performance issues, so use it only for read-modify-write sequences.

To learn more, read Stefano Demiliani’s blog, Dynamics 365 Business Central: locking down IsolatedStorage reads.

Caching issues using SetLoadFields for partial records

Duilio Tacconi tackles a thorny issue using the SetLoadFields method for partial records.

It turns out that caching does not always work the way you think it should, or, as Tacconi says, may not work at all, and this can create major performance issues.

Tacconi breaks down the problem and offers advice on when to use SetLoadFields in his blog, Partial Record vs NST Caching : the strange case of Calculate Low Level Code.

Moving from NAV to BC? What really happens

A common question clients ask: “What actually happens when we move from Dynamics NAV to Business Central?”

It turns out it isn’t one move. Instead, it’s an upgrade, then a migration.

First, NAV is upgraded to a Business Central version that can be migrated to the cloud; then it is migrated to the cloud. The real question is whether to perform a full migration or a reimplementation.

Mohana Yadav breaks down the process and offers guidance along the way in his blog, NAV to Business Central: What Actually Moves, and What Needs to Change?

AI development tools for AL

As software development moves more and more to AI, developers are utilizing multiple AI tools to ensure their code is bug-free.

In his blog, Astra + Fable, a power couple for AL?, Erik Hougaard offers a practical example by building and debugging a rental application for Business Central using two tools: Astra and Fable.

One wrote the basic code, while the other reviewed it and found bugs or areas that needed more attention.

Check out Erik’s blog to learn more.

Are you interested in Dynamics NAV and Business Central development? Check out our collection of NAV/BC Development Blogs.

Read “How To” blogs from ArcherPoint by Cherry Bekaert for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.

The post Dynamics Business Central / NAV Developer Digest – Vol. 561 appeared first on ArcherPoint.

That’s because an ERP implementation rarely happens under ideal conditions. There are deadlines to meet, business operations to protect, employees to train, integrations to rebuild, and years of data and processes to manage.

So, companies make compromises.

They migrate data they aren’t sure they’ll need. They recreate familiar workflows because users already understand them. They install replacements for old add-ons. They adopt standard security roles because redesigning permissions would take more time. And they automate processes without first asking whether those processes still make sense.

The system goes live. Everyone moves on.

Five years later, some of those hasty decisions start to show up.

The good news is that go-live wasn’t your last opportunity to get the ERP right. In fact, after several years of real-world use, you might be in a better position to optimize it than you were during implementation.

Here are five places to start:

How to optimize your cloud ERP after go-live

Cloud ERP optimization starts by revisiting the decisions made during implementation. After several years of real-world use, organizations should reevaluate data quality, security roles and permissions, legacy customizations, business processes and automation, reporting, and system integrations to determine whether the ERP still reflects how the business operates today.

1. Your ERP doesn’t need to be a museum of your old data

One of the hardest decisions during an ERP migration is deciding what data to bring with you.

When there is uncertainty, the safest answer can seem to be “everything.”

Years later, companies might find themselves maintaining old customer and vendor records, obsolete items, inactive accounts, duplicate records, historical transactions, unused fields, and inconsistent master data that no longer provides much business value.

Beyond filling up your storage, poor-quality data can affect reporting, search, analytics, integrations, and automation.

Five years into your cloud ERP journey, revisit your data strategy:

• Identify which master records are inactive or duplicated.
• Standardize naming and classification conventions.
• Review which historical information must remain readily accessible versus what can be archived, based on business and regulatory requirements.

Then look beyond the ERP.

Has the organization added CRM, eCommerce, warehouse, planning, expense, payroll, or other applications since implementation? If so, determine which system should own each type of data and how changes should flow between systems.

This not only reduces your database storage requirements but also makes the information more accessible to your users and, especially, to automated systems.

2. Reassess ERP roles, permissions, and security

Security and permissions often receive enormous attention immediately before go-live—and not always for the right reasons.

The priority is often focused on making sure everyone can do their jobs on Monday morning.

Default roles get assigned, and then permissions are broadened when users encounter roadblocks. Employees change roles, but their permissions aren’t always updated to reflect their new assignments. New employees inherit access privileges that were created for someone else. Temporary exceptions are never revisited and become permanent.

Five years later, the ERP’s access model might bear surprisingly little resemblance to the company’s organizational structure.

This is a good time to revisit ERP security from first principles.

Start with roles rather than individuals. What should someone in accounts payable, purchasing, warehouse operations, sales, or financial management actually need to see and do? Where should duties be separated? Who can create vendors, change bank information, approve purchases, post transactions, issue credits, or modify sensitive financial data?

Then compare that model with actual permissions.

This isn’t just an IT exercise. Finance, operations, HR, security, and business leadership should participate because access reflects business responsibility and risk, not merely system configuration.

And be sure to make regular security reviews a priority. Employee and organizational changes make periodic access reviews essential.

3. Reevaluate legacy ERP customizations and add-ons

Stop rebuilding your old ERP inside your new ERP.

This might be one of the most expensive implementation mistakes.

During migration, users understandably ask: “How do I do what I used to do?”

That question can drive companies to recreate familiar screens, reports, workflows, customizations, integrations, and add-ons in the new ERP.

It makes the transition easier, at least at first. But taken too far, it can result in a modern cloud platform running yesterday’s business processes.

Five years later, it’s worth inventorying every customization and add-on and asking why each one exists:

• Does it address a genuine competitive or regulatory requirement?
• Does the current ERP now provide that capability natively?
• Is the add-on still supported and valuable?
• Was the customization built because the old system couldn’t handle a process that the new platform handles differently?

Most importantly: If you were designing this process today, would you still design it this way?

Don’t eliminate customization simply for the sake of being “standard.” Some custom capabilities create genuine business value. The objective is to distinguish strategic differentiation from historical baggage.

4. Optimize business processes before you automate them

Don’t automate a process you should eliminate.

If a process is inefficient, automation only makes that inefficient process run faster.

Imagine an old purchasing process that requires information to move through spreadsheets, emails, manual approvals, duplicate data entry, and several handoffs. Moving those same steps into automated workflows might reduce some manual effort, but it doesn’t necessarily make the underlying process more efficient. In fact, automating a process without optimizing it first will only make bottlenecks more pronounced.

After several years in the cloud, take a fresh look at your most frequently used workflows.

Start with the outcome rather than the existing procedure:

• What is this process supposed to accomplish?
• Which steps add control or value?
• Which steps exist because of an old system limitation?
• Where is information entered twice?
• Where do employees leave the ERP and use email or spreadsheets to finish the job?
• Where do approvals sit unnecessarily?

Then simplify before automating.

The best automation projects often begin by removing steps rather than automating them.

5. Revisit ERP reporting, KPIs, and decision-making

ERP implementations tend to produce long lists of reporting requirements.

Five years later, some of those reports have never been opened. Instead, your employees have created dozens of spreadsheets outside the ERP to answer questions no one anticipated during implementation.

It’s time to revisit those reports and KPIs you thought you needed. Look at how your managers actually run the business today:

• Which reports are used? Which are ignored?
• What information gets exported to Excel every week?
• Which numbers require manual reconciliation?
• What questions still require contacting another department for an answer?

Then redesign reporting around decisions rather than reports.

After five years, you know far more about what people actually need than you did at go-live.

Bonus: Reevaluate your ERP integrations

Your application landscape probably hasn’t stood still.

New eCommerce platforms, CRM systems, warehouse technologies, analytics tools, banking applications, industry solutions, and other systems might have been added since your ERP implementation, and integrations might have accumulated over time.

Eventually, nobody is looking at the architecture as a whole.

Now is a good time to map it again.

Identify which applications exchange data, the direction of information flow, which system owns each data element, where duplicate information is maintained, and where manual intervention still bridges gaps.

You might discover that an integration created five years ago is no longer necessary or that a new integration could eliminate an entire manual process.

Your cloud ERP implementation isn’t finished

The most important lesson five years after a cloud ERP implementation might be that an ERP should never be treated as a finished project.

Business processes change. Employees change. Customers change. Technology changes. And cloud ERP platforms continue to gain capabilities after implementation.

Modern ERP platforms such as Microsoft Dynamics 365 Business Central are designed to add capabilities through regular updates. Business Central receives two major release waves each year, with continuous updates between them. This creates an opportunity to periodically reconsider what the platform can do today, rather than assuming the system is limited to what it did at go-live.

Capabilities across Business Central and the broader Microsoft ecosystem, which includes Power BI, Power Automate, Power Apps, and Copilot, also create options that might not have existed when your organization originally implemented its ERP.

Start by asking, “If we were implementing the ERP we already own today, knowing everything we’ve learned over the last five years, what would we do differently?”

You might find that the next major improvement to your ERP doesn’t require replacing anything.

It simply requires taking a fresh look at what you already have:

• Review your data
• Reassess permissions
• Challenge customizations
• Simplify processes before automating them
• Rebuild reporting around the decisions people make today
• Reevaluate your integrations

Get more from the ERP you already have

Your ERP shouldn’t be frozen in time since you went live. As your business, processes, and technology change, you have opportunities to improve your data, security, workflows, reporting, integrations, and use of automation.

Contact ArcherPoint by Cherry Bekaert today. We can help you take a fresh look at your Business Central environment, identify what’s no longer working as well as it could, and find practical ways to get more value from the platform you already own.

The post Cloud ERP Five Years Later: What Companies Wish They Had Known appeared first on ArcherPoint.

A warehouse full of product can seem reassuring: Orders can be filled, customers can be served, and purchasing has a buffer against supplier disruptions. But from a financial perspective, every pallet, case, and item sitting on a shelf represents cash that has already left—or will soon leave—the business.

Not all of that inventory is equally valuable. Perhaps more importantly, not all the cash it represents is equally recoverable.

Some inventory might be sitting in the wrong warehouse, while some more is becoming obsolete or approaching an expiration date. And some might exist in the system but not actually be where the system says it is, or not be there at all!

So, instead of asking, “How much inventory do we have?”, the better question is, “How much of our inventory is actually working for us?”

For distributors, answering that question requires better visibility—not just into inventory quantities, but into demand, location, age, movement, availability, cost, and risk.

Inventory visibility is the ability to accurately see what inventory you have, where it is, how quickly it is moving, what it is worth, and where it may be at risk. For distributors, that visibility directly affects working capital because every item purchased represents cash invested until the inventory is sold and payment is collected.

The inventory paradox: Too much and not enough at the same time

One of the most frustrating inventory problems is having too much inventory overall while still experiencing stockouts.

One location might have too much inventory while another repeatedly runs short.

The financial consequences extend well beyond the cost of the products themselves. Excess inventory ties up working capital and consumes warehouse space. Shortages can create expedited freight, emergency purchases, partial shipments, lost sales, and dissatisfied customers.

The company can end up paying twice: Once for inventory it doesn’t need and again for the consequences of running short on the inventory it does need.

Companywide visibility changes the conversation from “Do we have enough inventory?” to “Do we have the right inventory in the right place at the right time?”

Inventory aging: When stock becomes trapped cash

Finance typically knows the value of inventory. But knowing its value without knowing its age and velocity can hide an important cash-flow problem.

Slow-moving stock is a cash flow issue. As inventory ages, the probability of recovering its full expected value can decline. Products can become obsolete, customer preferences can change, or replacement models can arrive, making your existing inventory worth less than you paid for it.

Visibility into inventory aging and turnover allows finance, sales, purchasing, and operations to address the problem sooner:

• Should purchasing reduce future orders?
• Should sales move excess product through another customer or region?
• Should inventory be transferred between locations rather than replenished?

The earlier those questions are answered, the more options the distributor has.

For perishable and expiring inventory, the clock is literally running

For food, beverage, pharmaceutical, chemical, medical supply, and other distributors handling time-sensitive products, inventory has another dimension: Remaining useful life.

A refrigerated product isn’t simply 100 units on hand. Those 100 units might consist of several lots with different expiration dates. Likewise, pharmaceutical expiration dates represent the period during which the product is known to retain its strength, quality, and purity when stored according to its labeled conditions.

That means visibility needs to extend beyond quantity and location to information such as lot, expiration date, storage requirements, and remaining shelf life.

This is where practices such as FEFO—first expired, first out—become important. Instead of simply shipping the oldest inventory received, the organization prioritizes the inventory that will expire first.

The financial implications are substantial even without an outright stockout. A distributor that discovers aging product too late might have fewer options to transfer it, sell it, return it (where permitted), or otherwise avoid a write-off.

For refrigerated and frozen products, visibility also has a physical dimension. Knowing that a product exists isn’t enough if improper handling or storage has compromised it. In pharmaceutical distribution, FDA guidance explicitly ties product stability to labeled storage conditions, including temperature, humidity, and light exposure. These factors also add to storage, transportation, and regulatory compliance costs.

In these environments, inventory visibility becomes integral to product quality, traceability, compliance, and risk management.

Inventory accuracy: What if your inventory records are wrong?

Inventory accuracy is another problem that distributors don’t always connect directly to working capital.

If the system says there are 50 units in a bin but only 42 are physically present, every downstream decision based on the 8 nonexistent units is potentially wrong.

Sales might promise them. Planning might assume they’re available. Purchasing might decide not to replenish them. Finance might include them in inventory valuation.

How barcodes, RFID, and cycle counting improve inventory accuracy

Technology can help close the gap between physical inventory and system-reported inventory.

Barcode scanners and handheld devices can capture product, lot, serial, package, location, receipt, pick, and movement information at the point where work occurs rather than relying on later manual entry.

RFID can take this further. Because RFID doesn’t require the same line-of-sight scanning as conventional barcodes, tagged products, cases, or cartons can be captured automatically as they move through parts of the supply chain. GS1 US notes that RFID can improve real-time visibility into inventory levels and locations and increase the efficiency and accuracy of inventory tracking.

But technology alone doesn’t eliminate the need to count inventory.

Regular cycle counting can verify selected portions of inventory throughout the year instead of relying exclusively on a disruptive annual physical count. The real value isn’t simply discovering discrepancies. It also helps identify patterns. If the same warehouse, item category, process, or location repeatedly produces discrepancies, the distributor can investigate the operational cause rather than continually correcting the number.

Inventory visibility is a cross-functional responsibility

Perhaps the biggest mistake is treating inventory as solely an operations responsibility.

Each department needs a different view of the same inventory, a view that shows them what they need to perform their responsibilities.

A CFO might want inventory value, turns, aging, excess stock, and working-capital trends. Purchasing needs demand, lead times, incoming supply, and supplier performance. Warehouse managers need quantities, locations, picks, movements, and count accuracy. And sales needs reliable availability information before making commitments.

Visibility helps distributors recognize that inventory isn’t merely something stored in a warehouse. It is cash moving (or not moving) through the business.

How Business Central improves inventory visibility

Microsoft Dynamics 365 Business Central brings inventory together with purchasing, sales, warehousing, planning, and financial information. For distributors that require more detailed traceability, Business Central supports serial, lot, and package tracking, as well as expiration dates, and can prioritize items with the earliest expiration dates for outbound transactions using FEFO.

Business Central’s mobile app can scan 1D and 2D barcodes for serial, lot, package, journal, and warehouse activity information, helping capture data closer to where inventory is actually handled. Power BI can extend that foundation with dashboards and analytics that help management examine inventory value, movement, trends, and other operational and financial measures.

But technology only enables this visibility.

The real advantage comes from giving each department a common view of inventory and the ability to recognize where cash is being trapped before the problem shows up in the financial statements.

Put your inventory and your cash to work

Inventory shouldn’t just sit on the balance sheet. With better visibility into what you have, where it is, how quickly it’s moving, and where it’s at risk, you can reduce excess stock, improve inventory accuracy, and make better working-capital decisions.

ArcherPoint by Cherry Bekaert can help you optimize Business Central to improve your companywide visibility by connecting inventory, purchasing, warehousing, sales, and financial data, giving your teams the visibility they need to put more of your inventory (and your cash) to work!

The post Inventory Is Cash: Why Distributors Need Better Visibility appeared first on ArcherPoint.

My first instinct was that 33 weeks of documented AI learning gave me more than enough material. If anything, the problem would be cutting, deciding what to leave out of a series that had covered everything from basic prompting to diagnostic frameworks to building custom tools.

So I sat down with AI and started designing.

The first couple of iterations were fine. Solid structure. Logical flow. Good exercises. The kind of workshop you would expect from someone who has been writing about AI literacy for eight months.

But something felt off. It did not feel like what would have helped me on day one of my journey.

That is when I tried something I probably should have done from the beginning. Instead of designing forward from workshop objectives, I asked AI to go backward through my own journey.

Using AI to audit your own AI journey

I loaded the context of my full series and asked AI to do something specific: identify the skills I had actually picked up along the way, not the concepts I had written about, but the working skills I demonstrated across 33 weeks. Then I asked it to flag gaps, skills that were critical to accomplishing the work I had described but that I had never named, and skills I was not using that could improve my results.

What came back was not a generic checklist of things AI can do. It was a catalog of capabilities traced through my own experience, skills I could point to specific moments where I had learned them, specific articles where I had used them, and specific failures where I had discovered them.

And it was humbling.

A couple of things jumped out immediately.

First, there were skills I use in literally every AI conversation that I had never once named as teachable skills in 33 weeks of writing. I demonstrate iterative refinement constantly, treating every AI output as a first draft I shape through dialogue, but I had never called it out as a distinct skill someone needs to learn. I just did it, and assumed readers would absorb the technique by watching.

Second, and this one stung, there were simple, practical techniques I rarely use myself despite knowing they improve results. Specifying the format you want the output in, for example. I know this works. I have seen how much more effective it makes the output. And I almost never do it. It is the AI equivalent of knowing you should stretch before running and skipping it every time.

The four skills that actually matter

When I sorted everything, 33 weeks of learned skills, documented gaps, and instinctive habits I had never named, the inventory kept consolidating. Dozens of individual techniques, but they clustered into four fundamental capabilities that everything else builds on.

Think of these as layers. Each one depends on the one before it. You cannot evaluate output you have not learned to shape. You cannot manage a working conversation if you accept whatever comes back. And you cannot think strategically with AI until the mechanics of conversation become second nature.

Skill 1: Set the Stage. Everything that happens before AI generates its first response. Context, roles, examples, format, and knowing how to break big problems into smaller ones.

Skill 2: Read It Like a Skeptic. Everything that happens after AI responds. Evaluating output against your own expertise, spotting confident nonsense, recognizing when AI is telling you what you want to hear instead of what you need to hear.

Skill 3: Work the Conversation. The rhythm of real AI work, iterating on output, managing context, knowing when to push further and knowing when to start over.

Skill 4: Think Bigger, Think Better. Using AI for strategic thinking and blind-spot detection while knowing what to protect, what to verify, and when to override your own framing.

That is it. Four skills. Everything I have written about for 33 weeks either fits inside one of these or builds on top of them.

Now let me unpack what I actually found in each one, including the gaps I discovered in my own practice.

Skill 1: Set the Stage

This is where most AI education starts and stops: write better prompts. But when I mapped the full set of skills that actually shape what AI gives you, prompting was only part of it.

The foundational shift, the one everything else depends on, is understanding that you are having a conversation, not issuing a search query. That is what I wrote about in Week 1 when my son’s advice changed everything, and what I expanded in Week 3 with the Master Improv Actor framework. Most people approach AI the way they approach Google: type a question, get an answer, move on. Until that pattern breaks, nothing else in the inventory matters.

But “it’s a conversation” is only the starting line. The skills that actually set the stage go further.

Giving context is the thinking-partner shift: telling AI who you are, what you are working on, and why it matters before asking your question. Not because AI needs your biography, but because who you are shapes what useful advice looks like. I covered this in Weeks 1 and 3, and it is the core of everything I teach about Shift 1. This one I got right.

Assigning roles is the Improv Actor concept from Week 3. Give AI a character to play. “Act as a process improvement consultant” produces fundamentally different output than asking the same question without a role. Covered well.

Then the gaps start.

Providing examples of what good looks like is one of them. I touched on this in Week 28’s production-prompting work, but I never named it a fundamental skill. It is one. When you show AI an example of the writing style you want, the analysis format you need, or the level of detail you are looking for, the output quality jumps immediately. It is the difference between telling someone “write me something professional” and handing them a document and saying “like this.”

Specifying format and constraints is the gap that surprised me most, not because I did not know about it, but because I know it works and I still skip it. Tell AI you want a bulleted list, a three-paragraph summary, a table with specific columns, a response under 200 words. The output improves dramatically. I have scattered this technique across the series without ever elevating it to the fundamental skill it is. It might be the single most practical thing you can teach someone in their first hour with AI, and I had been treating it as too simple to be worth naming.

Breaking big problems into smaller ones is the last gap in this cluster. My diagnostic framework from Week 16 does this implicitly; the whole “Review of Systems” approach is about decomposing vague frustration into examinable components. But the general technique of breaking a complex request into steps before asking AI to execute is a transferable skill I never taught as such. Your first instinct is to dump a massive question on AI and hope for the best. The skill is learning to sequence: first help me understand the problem, then help me evaluate options, then help me draft a solution.

Skill 2: Read It Like a Skeptic

This is the skill that separates people who use AI from people who use AI well. And it is where I discovered the gap between what I covered conceptually and what I practice daily.

Week 4 addressed AI limitations. Week 3’s “Yes, And” principle explained why AI tends to agree with you. Week 31 explored what happens when human experts hallucinate with the same confidence as AI.

The concepts are there. The practical skills need work.

Spotting confident nonsense is the first one. AI does not hedge when it is wrong. It delivers fabricated information with the same tone and structure as accurate information. Week 31 addressed this philosophically, the idea that humans hallucinate, too. But the practical skill of catching fabrication needs more attention than I gave it. There is a specific list of things AI is reliably bad at: basic math, counting items in a list, knowing about events after its training data ends, and, critically, admitting when it does not know something. I never compiled that list in the series. I worked around these limitations instinctively. I did not teach anyone else to do the same.

Detecting sycophancy goes beyond knowing that AI agrees with you. It is the active skill of noticing when AI is flattering your ideas instead of examining them. Given everything I wrote in Week 30 about the Knowledge Trap, how having more information does not translate to persuasive power, and Week 31 about the Expertise Paradox, this skill connects directly to the most recent arc of the series. If AI confirms your assumptions because it is architecturally inclined to agree with you, and you accept that confirmation because it feels like validation of your expertise, you have built a feedback loop that makes you more confident and less accurate at the same time.

The practical counter-skill is to make it a habit to ask AI to argue the other side, find weaknesses in your reasoning, and tell you what you might be missing. I do this reflexively now. If someone had taught me to do it explicitly in my first week, it would have saved me months of accepting mediocre output because AI told me it was great.

Checking your own framing is the deepest version of this skill, and it is the one I had not fully articulated until now. AI reflects your framing back to you. If you describe a problem as a technology problem, AI gives you technology solutions. Describe the same problem as a people problem, and you will get entirely different recommendations. The pushback exercises from earlier weeks address this partially, but the core skill, pausing to ask whether your framing might be shaping the answers you are getting, is distinct from just pushing back on AI’s output. You are pushing back on your own input.

Skill 3: Work the Conversation

If Skill 1 is how you start and Skill 2 is how you evaluate, Skill 3 is how you work, the rhythm and mechanics of real AI collaboration over the course of a conversation, across conversations, and across platforms.

This cluster contains the skill I have most consistently demonstrated without ever naming it.

Iterative refinement might be the most important unnamed skill in the entire series. Every experienced AI user does it: treat the first output as raw material, then shape it through follow-up instructions, corrections, and redirections. “That is good but make it more concise.” “Keep the structure but change the tone.” “The second section is strong, rebuild the first to match it.” I do this in every article I write, every framework I develop, every client deliverable I produce. Thirty-three weeks of demonstrating it. Zero weeks of calling it out as a skill someone needs to learn.

Context management, summarizing where you are mid-conversation, resetting when things drift, I covered in Week 8’s second pillar. Carrying context between conversations through copy-paste workflows and cross-platform transfer has been a recurring theme. Those parts of the map had labels.

Knowing when to start over did not. This is a real gap. I never addressed the skill of recognizing that a conversation has gone sideways and that a fresh start will be more productive than ten more rounds of refinement. There is a moment, experienced users know it, where the AI has accumulated enough confused context that it is working against you rather than with you. The right move is to open a new conversation, paste in a clean summary of what you actually need, and start fresh. I do this regularly. I never mentioned it.

Knowing when to stop is the twin of knowing when to start over. Diminishing returns are real. I have burned more time than I would like to admit refining output past the point of meaningful improvement, running a piece of writing through too many rounds when a few rounds was probably ninety percent of the way there. The skill of recognizing “good enough” is particularly important for busy leaders who could easily spend two hours polishing something that needed twenty minutes. Nobody teaches this because it is not exciting. But it might save more time than any other skill on the list.

Skill 4: Think Bigger, Think Better

The first three skills are about working with AI. Skill 4 is about working with AI, using it as a lens to see things you could not see before, while maintaining the judgment to protect yourself and your organization.

Using AI to find problems you have normalized is the diagnostic work from Weeks 15 and 16, the unlocking questions, the seven barriers framework, and the “Review of Systems” approach. It is the category of AI use that I believe has the most transformative potential, not solving the problems you already know about, but revealing the ones you have stopped noticing.

Using AI to pressure-test your own ideas is one I use constantly, but never named as a transferable technique. Before I present a proposal, share a recommendation, or publish an article, I run it past AI as a skeptical audience. “What is the weakest argument here? What am I assuming that might not be true? If someone wanted to tear this apart, where would they start?” It is a rehearsal for every difficult conversation and is available to anyone with a subscription and the habit of asking.

Think Before You Research is the technique from Week 26 where you design your approach collaboratively with AI before deploying it to expensive deep research modes. This is a strategic skill that saves both time and money and represents the kind of second-order thinking that develops naturally after the first three skills become habitual.

Then the safety layer, which I would argue should be taught on day one, even though it only fully makes sense after you have been working with AI long enough to feel tempted to skip it.

Knowing what not to share comes from the security tiers in Week 2. This is non-negotiable and straightforward, but people need to hear it early and often: not all AI platforms protect your data equally, and what you share in a free tier conversation might be used for training.

Understanding that AI output is a draft, not a deliverable, is the editorial board concept from Week 5. AI gives you raw material. You give it judgment, verification, and accountability. The moment you submit AI output without review is the moment you have delegated your professional reputation to a system that cannot be held responsible for what it produces.

Your Week 34 Challenge: Audit Your Own Skill Gaps

1. Rate yourself honestly against the four skills. Not “have I heard of this,” that is awareness, not literacy. The question is: do you do this consistently, without thinking about it, in your actual work? Set the Stage, Read It Like a Skeptic, Work the Conversation, Think Bigger, and Think Better. Where is your biggest gap between knowing and doing?
2. Try one unnamed skill this week. Pick the simplest one: tell AI exactly what format you want before you ask your question. “Give me this as a three-paragraph summary” or “Respond in a table with columns for pros, cons, and my suggested action.” Notice what happens to the output quality.
3. Ask AI to audit you. Share a few recent AI conversations and ask: “What skills am I using well? What am I not doing that would improve my results?” It is the same exercise I did with my series, scaled down to your own practice. The answers might surprise you.
4. Name one skill you use but have never articulated. Everyone who works with AI regularly has at least one technique they have developed instinctively but could not explain to a colleague. Name it. The act of naming makes it transferable to your team, your organization, or your own intentional practice.

The Bottom Line

Thirty-three weeks into this series, I thought I had a pretty good map of AI literacy. Building a workshop that had to fit into 90 minutes revealed that my map had skills I had never labeled and routes I had never drawn, not because I did not travel them, but because I had stopped noticing the turns.

That is not a failure of the series. It is how practitioners actually learn, by watching someone do it before anyone names what is happening. But demonstrating a skill and teaching a skill are not the same thing. The workshop forced that conversion: you cannot teach someone a skill in 90 minutes if you cannot name what the skill is.

Everything I have learned clusters into four capabilities: Set the Stage, Read It Like a Skeptic, Work the Conversation, and Think Bigger and Think Better. They build on each other in that order. And the gaps I found were not in the advanced skills, they were in the simple, practical habits that experienced users do without thinking. Specifying format. Providing examples. Knowing when to stop. Knowing when to start over.

Simple enough that they feel unworthy of an article. Foundational enough that everything else builds on top of them.

If you have been following this series, you have been watching many of these skills in action for months. Now you have names for them. And naming something is the first step to teaching it, to your team, to your organization, or to yourself on the days when you know better but skip the stretch anyway.

This post is part of my “AI Over 40” series. It first appeared on LinkedIn: The Four Skills Behind Every AI Conversation

Read more AI and Copilot blogs.

The post AI for the Over 40 – Week 34: The Four Skills Behind Every AI Conversation appeared first on ArcherPoint.

In Business Central you extend the standard application by subscribing to events, not by editing base code. The hard part is knowing which event fires, and when — and once you know, getting from that event to working AL code without breaking your flow in and out of the editor. The Event Recorder answers the first question in about a minute. Running it through VS Code answers the second.

Start from VS Code

In VS Code, press Ctrl+Shift+P and run the AL: Open Events Recorder command. This opens the Event Recorder page without leaving your editor, so the trip from finding an event to writing its subscriber stays in one place.

You’ll still need a second surface to perform the action you’re recording — open a browser tab on the same environment, and use a sandbox, not production.

Record the action

1. In the Event Recorder page, choose Record Events > Start, then confirm.

2. In the browser tab, perform only the action you want to capture, such as posting one sales order.

3. Return to the recorder and choose Stop. The captured events appear in the order they were called.

4. Locate the event you need from the captured list of triggers and custom events.

Reading the results

Each row tells you the event name, its type, and the object that published it. Order matters: an OnBefore() event is your chance to validate or block, while an OnAfter() event is where you write follow-up logic once the standard work has succeeded. Pick the narrowest event that still sees the data you need.

Back to VS Code: from Business Central Event Recorder to AL snippet

Choose Get AL Snippet on the row you want. Business Central returns a ready-made subscriber signature that you paste straight into a codeunit in VS Code — the same editor you started from.

Three things to watch

• Nothing is saved. Recorded events vanish when you refresh or close the page. Copy what you need before you navigate away.
• Record one action at a time. A short list is a readable list. Batch several actions together and the useful event is buried.
• Not every extension point appears. The recorder shows what was raised in that run. If your scenario branches, record the branch you actually care about.

Used well, the Event Recorder turns event discovery from guesswork into a five-minute step. It keeps customizations attached to published events rather than to base code, which is what keeps them upgrade-safe.

Looking for the fundamentals first? See How to Use the Event Recorder in Dynamics NAV/BC for the basic recording workflow.

The post Event Recorder to AL Code: A VS Code Workflow in Business Central appeared first on ArcherPoint.