Transparency is something that clients value. Even if it’s to hear “Your traffic went down last month,” they appreciate that more than utter silence from a digital agency they’re paying every month to work on their behalf.

At the same time, you never want your communications with clients to revolve around generic bad news or good news.

“You gained 5 followers on Facebook!”

“No one downloaded your lead magnet last week.”

“Engagement is up 13%.”

There’s very little value in communicating context-less stats to your clients in this manner.

This is why it’s a good idea to prepare monthly and annual digital marketing reports for your retainer clients. Not only does this give you a chance to share an overview of how their brand is performing online, you can lend your professional insights into what’s going on, why and what you plan to do next.

In this post, we’ll look at why it’s worth it to create these monthly reports as well as tips on how to prepare them.

Are Custom Marketing Reports Necessary?

Your marketing and advertising platforms have dashboards that contain “insights” about your campaigns. The only problem is that what they call insights are usually nothing more than numbers.

For example, here is a Traffic Acquisition table from Google Analytics:

There are ways to set up automated reporting in platforms like Google Analytics. And you can aggregate different data sets so that you don’t get individual reports for Acquisition, Traffic, Conversions, etc. But for many clients, these reports just look like a bunch of numbers. And, in many cases, these tables and charts include terminology they don’t understand.

For instance, what would “Cross-network” mean to them? Or “Engagement rate”? What’s more, even if they did know about the general traffic acquisition types, do they really understand what the data is telling them within the context of the work you’re doing?

This is why a custom monthly report is necessary. You can and should include these data sets from your marketing platforms within the report. However, you also need to describe what’s being depicted and analyze the results in order for it to have meaning for your clients.

Why You Should Be Preparing Marketing Reports Every Month

The biggest reason is transparency. Imagine shelling out a few hundred or thousands of dollars to a company every month. They promise they’re doing the work you pay them for, but there doesn’t seem to be much to show for it. And with something like marketing, it can be a slow burn.

How long do you think you’d be willing to keep paying a vendor with no proof or payoff?

Your monthly marketing report is your chance to be transparent about what’s going on. Even if you’re not giving them a play-by-play of every website update you make or post you put on Facebook, you’re showing them the end results—and that’s often the only thing that clients care about anyway. It’s why they’re outsourcing this to you in the first place, after all.

There are other benefits behind creating custom reports from month to month. For example:

Monthly reporting requires you to make time to carefully review the results of your work every month. This helps verify you’re delivering results and achieving the goals you set out to accomplish at the start.

If you find that something isn’t working, these reports enable your team to make informed decisions regarding the strategy. You might decide to stay the course a bit longer, adjust or even start over. The point is, you’ll know if something isn’t working right away, which will allow you to take timely and data-driven action to change it.

As for your clients, monthly reports can change how they view what you do. By creating reports that focus on the outcomes, your clients will see marketing and advertising as a valuable investment; not just money that flows out of their wallets each month.

The more satisfied they feel with your investment, the less likely they are to question your decisions or to feel untrusting of the whole process. Your monthly reports establish your digital agency as one that is transparent, hard-working and professional.

So, if you’re looking to hold onto your monthly retainer clients for longer, these reports can help instill a good amount of trust in them.

Tips for Preparing Digital Marketing Reports for Clients

Just because you create a report doesn’t mean your client is necessarily going to read it. To make it worth their time, here are some tips on how to prepare it:

1. Bring All the Data Together

Typically, when preparing marketing reports, there are going to be two components. One is the raw data set from the time period. The other is going to be the summary and analysis that explains what the data means.

This tip has to do with the raw data.

Unless you’re using an omnichannel marketing platform to aggregate your marketing data, you’re going to have to bring it all together on your own. My favorite way to do this is with a spreadsheet.

Here’s an example of a monthly data pull I do for one of my clients in Google Sheets:

Look along the bottom and you’ll see all the tabs I use to centralize my client’s marketing and advertising data:

• Domain Reputation (from Moz)
• Google Business (local search metrics)
• PageSpeed Insights (performance metrics)
• Google Ads (advertising metrics)
• Google Analytics (website metrics)
• Google Search Console (SEO metrics)
• Facebook (social media metrics)

I like this approach for a number of reasons.

To start, it allows me to choose which data points my clients see. I’m not hiding anything from them. I’m just keeping their focus on the most pertinent data.

For example, for Google Business, there’s a data point for Bookings. Since my client doesn’t take bookings through Google, it doesn’t make sense to include that information in the report. I strip out other irrelevant data from the other tabs.

By putting data into spreadsheet, I’m also about to highlight fields, add comments and emphasize certain cells. With a PDF printout from the source, you really can’t make the data your own. You just have to run with what you get and then explain what the client should focus on in the summary. And I’d rather keep the presentation of data as clean and on-point as possible.

2. Include Benchmarks Data and Goals

Another reason I prefer using spreadsheets to share marketing data is because it allows me to show how the metrics have changed over time.

Typically, when you get a report from a marketing platform, it either provides no information about what happened in the past or it’ll show you a percentage change from month to month.

But in marketing we don’t look at data in isolation like that. The changes that happen over time tell us a story about what’s happening and can also shed light on why.

So when putting together your data sets each month, you should include not only recent history, but a benchmark. Now, what this benchmark ends up being will depend on what the data is and how long you’ve been tracking it.

For example, I’ve only just begun working on this campaign this year. So, for me, the benchmark reference is February 2026. This was the month before I began working for the client. By keeping this data in each spreadsheet, I’m able to see what their typical performance was before we began optimizing our efforts.

It’s not enough to just look at the starting point though. I include all the months in between so I can see changes from month-to-month as well as over time.

Now, let’s say you’ve been working with a client for over a year, you might want your benchmark to be:

The average monthly metrics from the previous calendar year.

This will allow you to compare your current performance against what was the typical result last year. This is a good way to do it if you have enough data and things remained relatively steady throughout the year.

Alternatively, it might make more sense for your benchmark to be:

The same month’s metrics from the previous year.

So, if you’re working on pulling data for August 2026, you’d use August 2025 as your benchmark. This is mostly beneficial for brands that have seasonal peaks and slumps. That way, if August tends to be slower, you’re not gauging performance against the entire year’s average (which may be much higher than your typical slow period).

I also think it’s valuable to include goals within your data sets when possible. For example, here are the goals I’ve set for PageSpeed Insights:

While 100 would be an ideal score for the four core web vitals, it’s not necessary. Sure, Google looks favorably on websites that perform well in these four areas, there are so many other factors that go into ranking. So, I’m not going to go crazy trying to achieve a perfect score. With the exception of Mobile Performance, all of my goals are in the green zone (90 to 100), even if they’re not perfect 100s.

I also think it’s important to consider the context of what you’re working with. For some webpages (especially on mobile), it’s really hard to get your score into the green no matter what you do. So, my goal is to improve from month to month whenever possible.

As you can see, we experienced a major drop last month in mobile Performance after I redesigned the homepage. So I spent this past month reworking it and optimizing it for speed. I’m confident that when I check again in July, we’ll be back up over the goal line.

This is why we include these relevant details in the data pull. It gives us a frame of reference as to where we came from, where we’re at and where we need to go.

3. Write the Report for Your Intended Audience

Now let’s move over to the summary and analysis side of things.

When writing these reports, it’s important to take into consideration who will be reading and using the report.

For example, I have one client who prefers a TL;DR (too long; didn’t read) approach. They have outsourced all of their marketing and advertising to me, and would prefer I take the reins. At the same time, they want to make sure they’re seeing an ROI on the work I do.

So, I send their summary over email vs. putting it into a document. It’s one less click, step and hurdle to keep them from seeing the report.

I keep it as short as possible, highlighting the most important points under each marketing channel I manage. I call out unexpected changes, big wins and ongoing trends. I also include any changes I plan to implement in the strategy.

Now, for other clients, I prepare more in-depth reports.

I create a branded (to them, not me) document with a consistent layout from report to report. Within it, I include:

• A formal summary cover page
• Explanation about why I believe this month’s performance turned out as it did
• Details about any changes I plan to make in the next month
• Deep analysis for each of the data sets I looked at
• Summary at the end with a list of action steps I plan to take

If you’re not sure how your client will receive the report you’ve prepared, start with something formal. If it’s too much for them, cut back to a more concise summary email and see if that gets them interested.

One other thing I’d recommend is incorporating citations. For example, I sometimes include external reference points to support some of my insights and recommendations. It just depends on who the client is.

For instance, whenever I do email marketing, I include a link to the recent study on the average and optimal open rates by industry, like this Klaviyo post. This way, if my client wonders why I set the goal open rate to 33.1% for their ecommerce shop, I can point them to real user data.

4. Organize Your Report

One thing I do for all my reports is to organize them. Not only does this mean breaking them up into sections with well-labeled headings, but I put the data in a logical order. For instance, I’d never place MailChimp data at the top, followed by Google Analytics, Facebook and Google Business.

To me, the headings tell a logical story, so they need to be ordered accordingly. I prefer to start at a high level with domain reputation, move to the website or app, tackle SEO and PPC, and then cover the different marketing channels (social media, email, etc.) last.

Whenever possible, I like to integrate data visualizations so the client doesn’t have to refer back to the data set. But I try not to overdo it. I don’t want to embed every table from the spreadsheet or the marketing platforms. I just use them to emphasize or elaborate on the points that need it.

For example, this is a “report” I created for this article:

It’s full of Lorem Ipsum text, so there’s nothing meaningful here. I just wanted you to get a sense for how these types of documents can be ordered and how to integrate data visualizations to keep things visually interesting.

I would also recommend writing these sections the way you would the content of an email or website. Shorter paragraphs are best. If you can use bullet points to list out data or recommendations, that would be helpful, too.

Wrapping Up

I know that marketing reports might not be the most exciting thing to prepare. But they’re incredibly beneficial for both you and your clients.

A well-prepared analysis (be it short or long) can point you to what’s working so you can reinforce those practices, and also show you what’s not so you can adjust your strategy. Instead of reacting when something hasn’t been working, you can proactively align your decisions so you get the best outcome.

For clients, it gives them a level of transparency needed to fully trust you. When it comes to something like organic marketing, it can take some time before they see the results of it in terms of leads, sales and so on. But that doesn’t mean that you need to stay quiet until then. These marketing reports can show how your work is slowly moving the needle forward—increasing their online brand authority, bringing in more traffic and more.

Learn about the tools available with Progress Sitefinity Insight analytics right inside your CMS.

Request Demo

The future of payments is being built for speed. The operations behind them still depend on trust.

Financial institutions are investing in real-time payment rails, open-banking APIs, ISO 20022 migration, embedded finance partnerships and digital experiences that make money movement feel increasingly instant. But the transaction itself is only one part of the payment lifecycle.

Behind every payment sits a wider operational ecosystem: reconciliation files, settlement reports, exception outputs, fraud review data, merchant and processor exchanges, treasury files, customer notifications, regulatory reports and audit records. These flows may not be the payment rail, but they help support an institution’s ability to process, reconcile, monitor and report on payment activity.

That is where managed file transfer (MFT) can continue to play an important role in modern payment operations. It is part of the operational backbone that can help financial institutions move payment-related data with security, consistency and governance in mind.

Real-Time Payments Still Create Back-Office Data Movement

Real-time payments change expectations around speed. Funds can move faster. Customers expect immediate confirmation. Businesses want faster access to cash flow. Banks and credit unions are being pushed to operate closer to real time.

But instant execution does not make every supporting process instant by default.

Financial institutions still need to reconcile transactions, manage exceptions, update internal systems, monitor fraud signals, support liquidity reporting, coordinate with processors and partners, and provide evidence for compliance and audit teams. Some of these workflows are API-based. Some are message-based. Many still depend on files.

A payment can settle quickly while reconciliation still depends on a scheduled file. A customer-facing experience can feel seamless while back-office teams still rely on batch exchanges between banks, fintech partners, processors and internal systems. A new payment rail can be modern while the operational data movement surrounding it remains fragmented.

One potential risk is that institutions modernize the transaction layer while leaving the supporting data layer fragmented or under-governed.

Open Finance Expands the Number of Data Handoffs

Open banking and open finance are changing how financial data is accessed, shared and embedded into new services. They are also increasing the number of participants involved in delivering those services.

In Europe, the European Commission describes its Financial Data Access framework as an open-finance proposal for responsible access to individual and business customer data across a broad range of financial services. In the U.S., the Consumer Financial Protection Bureau (CFPB) finalized a personal financial data rights rule in October 2024 (effective January 2025) and, in 2025, launched a formal reconsideration rulemaking, reflecting both the momentum behind data access and the ongoing policy debate over how it should be governed.

Financial ecosystems are becoming more connected. Banks and credit unions now exchange data with fintechs, payment processors, aggregators, corporate treasury platforms, risk systems, regulators and service providers. What was once a relatively closed environment is increasingly an ecosystem of handoffs.

That ecosystem requires different types of data movement. APIs enable real-time connectivity and customer-permissioned access. Payment messaging standards support interoperability. Streaming can support event-driven visibility. Data platforms support analytics and reporting at scale.

From a file transfer perspective, those handoffs now extend beyond traditional bank-to-bank connections to include fintech platforms, payment processors, cloud storage environments and third-party service providers. SFTP remains an important method for exchanging files, but institutions may also use HTTPS-based transfers, cloud integrations and APIs to initiate or coordinate file-based workflows. The challenge is managing these different endpoints and transfer methods with appropriate security controls and consistency.

File-based exchange still has a role within that mix, particularly for operational workflows such as end-of-day reconciliation, exception reports, partner extracts, merchant settlements, treasury updates and regulatory submissions. These files can form part of the control layer that helps institutions understand, verify and document what happened.

Richer Payment Data Raises the Bar for Operational Discipline

The industry’s shift toward richer, more structured payment data adds another layer of complexity.

ISO 20022 is often discussed as a messaging standard, but its value extends beyond formatting. Swift describes ISO 20022 as an open global standard that provides consistent, rich and structured data for financial business transactions, while Payments Canada notes that ISO 20022 supports more remittance information for automated reconciliation and straight-through processing.

Richer payment data can improve automation and insight, but it also raises expectations for how that information is handled across systems and partners. Different platforms may support different data formats or fields, creating challenges when exchanging, validating and reconciling payment information. If critical data is lost during conversion, arrives late or cannot be reliably matched across systems, institutions may struggle to realize the full benefits of modernization.

Modern payments are not only about moving money faster. They also require operational processes capable of handling the data generated around that movement.

Where MFT Fits in a Modern Payments Architecture

Managed file transfer should not be positioned as a replacement for APIs, payment messages, streaming platforms or real-time payment rails.

MFT addresses a different pattern: controlled file exchange across systems, organizations and workflows.

APIs and MFT can also work together. For example, a banking application might use an API to initiate the transfer of a reconciliation file to a payment processor or trigger a downstream workflow once a file arrives. This allows institutions to integrate protected, automated file movement into broader business processes without relying on manual handoffs.

File-based workflows often include reconciliation between internal systems and external partners, settlement reporting, exception processing, corporate payment files, merchant and processor exchanges, regulatory submissions, audit evidence and scheduled operational reporting.

As payment ecosystems become more connected, managing file exchanges across multiple partners and systems becomes more challenging. A delayed reconciliation file can slow exception resolution, a failed processor exchange can disrupt downstream reporting and inconsistent transfer processes can make it harder to onboard new fintech partners. When these workflows rely on legacy FTP, disconnected scripts or manual handoffs, institutions may struggle to maintain the security controls, visibility and reliability that modern payment operations require.

A modern MFT platform can provide a more centralized approach to these exchanges by applying configured security policies, automating repeatable workflows and maintaining audit records that give teams greater visibility into transfer activity and delivery status.

So now, instead of asking, “Did someone send the file?” teams can ask, “What does the transfer record show?”

Governance Becomes an Operational Priority

As institutions participate in broader open-finance ecosystems, operational dependencies multiply. There are more partners to manage, more sensitive data exchanges to oversee and more pressure to demonstrate that information is being handled appropriately.

Verizon’s 2025 Data Breach Investigations Report found third‑party involvement in 30% of confirmed data breaches, up from 15% the previous year. For financial institutions working with processors, fintechs, aggregators and service providers, third-party exchange is therefore an important governance consideration.

Payment-related files often contain personally identifiable information (PII) and sensitive operational data, including account details, transaction records, merchant data and financial reports. Institutions need visibility into how that data moves, who can access it, whether transfers succeed and what evidence exists when questions arise.

A governed file transfer model can help organizations answer practical questions: Can we gain visibility into critical payment-related file exchanges? Can we identify failed or delayed transfers? Can we apply consistent controls when onboarding a new partner? Can we maintain records of file transfer activity? Can we reduce manual handoffs without losing oversight?

These are not purely IT questions. They are questions of resilience and accountability.

Scaling Payment Operations Calls for Greater Automation

As payment volumes increase and operating windows shrink, manual file-handling processes become harder to sustain. Teams may still be checking folders, triggering uploads, renaming files, monitoring inboxes or manually confirming deliveries. That model may work at lower volumes, but it becomes difficult to scale well across real-time, always-on financial ecosystems.

Automation is essential, but it needs to be governed.

There is a meaningful difference between a collection of scripts and a controlled automation layer. Scripts can solve individual problems quickly, but they can also create hidden dependencies or lack consistent monitoring, error handling, documentation and ownership.

A governed MFT automation model can help standardize how files are moved, monitored, retried, escalated and documented across workflows.

Repetitive does not mean low-risk. A daily reconciliation file, settlement report, processor exchange or exception output may be routine, but each still supports business-critical activity.

Progress Automate MFT capabilities can help financial institutions automate and manage secure file exchanges across internal systems, external partners and cloud environments. The cloud-native platform supports centralized workflow management, scheduling, monitoring and audit visibility, with connectivity to SFTP and FTPS servers, internal network shares and cloud storage services such as Amazon S3 and Azure Blob Storage.

Progress-hosted and self-hosted agents allow transfers to run across cloud and on-premises environments. This approach can help institutions reduce manual processes, apply consistent security controls and maintain oversight of critical payment-related file workflows.

Modernization Requires the Right Tool for the Right Pattern

Modern financial institutions do not need to choose between APIs, payment messages, streaming, cloud platforms and managed file transfer. Each addresses a different operational need.

APIs support real-time connectivity and open-finance experiences. Payment messaging standards support interoperability across rails and institutions. Streaming can support event-driven monitoring and analytics. Data platforms support reporting, modelling and enterprise-scale insight.

MFT can support protected and automated file movement with audit capabilities across internal systems, external partners and workflows where organizations may have regulatory obligations.

That is the right context for MFT in modern payments. Not as legacy infrastructure nor as a substitute for real-time payment technologies. Rather, as a governed operational layer for the file-based data movement that still underpins banking.

Build the Operational Backbone Modern Payments Depend On

Modern payments create new opportunities for financial institutions: faster service, richer data, more connected products and better customer experiences.

Realizing those opportunities also depends on the operational infrastructure surrounding the transaction.

For file-based workflows, financial institutions need a data movement strategy that supports secure transfer, automation, auditability and centralized control.

The Progress Automate MFT platform helps financial institutions modernize the file-based workflows behind payment operations, with capabilities designed to help protect sensitive file exchanges, automate recurring transfers and support centralized monitoring and audit visibility.

Moving money faster is only part of the challenge. Modernization also depends on moving the data behind it with appropriate security controls and greater reliability and visibility.

Want to see Automate MFT in action?

Request a Demo

Your web team is ready to connect an AI agent to the content management system (CMS). The first test looks harmless. Let the agent update stale copy on a few pages, then see how much time the editors save.

The text the agent rewrites is easy to inspect. The account and permissions the agent uses carry the larger risk, and those never make it into the demo. If the agent uses a shared service account, broad publishing permissions and every source the CMS can reach, a small editing task arrives with much larger authority. Before the first run, the editor and platform owner need to agree on the guardrails the CMS will enforce.

Start with Who’s Responsible for What

Before connecting an AI agent to your CMS, establish who’s responsible for keeping it within the rules. The platform owner and editor look at the same agent from different sides. One controls what the agent can access and do. The other makes sure its content changes are appropriate.

The table below shows how those responsibilities are divided. Think of it as a quick reference for who’s accountable for what, not a substitute for checking that the controls actually work.

Know What Kind of AI Agent You Are Connecting

An AI agent inside a CMS is software that analyzes content and takes a defined action. That action might be suggesting a revision, changing a field or moving an item into a workflow stage. Those are different levels of authority, even when the product page uses one friendly word for all three, and the permissions should reflect the difference.

Progress Sitefinity, a CMS with built-in AI agents, shows why the distinction matters. Its Brand Voice and Style Agent reviews content against rules your team configures. With an active AI subscription and version 15.4.8631 or later, the Brand Voice and Style Agent presents suggestions for an editor to apply or reject. A custom agent can use configured tools, but Sitefinity requires a person to approve content changes before they are applied. Know which kind of agent you are deploying before anyone assigns credentials. “It’s just an assistant” is not a permissions model.

Give the Agent Its Own Identity

An agent’s identity is the dedicated CMS user account it acts under. An Access Key authenticates API requests as that user. An OAuth 2.0 client can instead be authorized to access the CMS on the user’s behalf. A separate identity lets the CMS attribute each content change to the agent’s account and lets the platform owner revoke the agent’s access without disabling other users or connections.

One common setup uses a dedicated backend user with an Access Key or an OAuth 2.0 client authorized to access the CMS on that user’s behalf. Make a test change and confirm that the CMS’s change history attributes it to the dedicated user. If the change history names a shared user instead, the credential proved access but not attribution, and “the service account did it” is where accountability goes to retire. Give the credential an owner and renewal date, then grant the user only the permissions the agent needs.

Separate Editing from Publishing

Identity tells the CMS who is acting. Permissions decide what that identity can do. An agent asked to revise body copy doesn’t need permission to delete entries, change templates, unpublish live pages or approve its own work. That last one has a way of slipping through, and anything grading its own homework will give itself full marks every time.

CMS roles group permissions, while approval workflows decide who may move content toward publication. The platform’s approval workflow lets an administrator create one, two or three review levels and assign approvers to each level. A separate role can let the agent edit and submit content without allowing it to approve or publish.

Configure both sides of the permission boundary. The agent may edit approved fields and submit the item for review, but it may not approve, publish or delete content. An agent allowed to approve its own edit has bypassed the separation the workflow was supposed to provide, which leaves you with an expensively configured decoration.

Record Every Change and Keep a Rollback Path

Permissions limit what an agent can change. A change record captures what happened within those limits and gives the editor a rollback starting point when a revision is wrong. The Progress Sitefinity Audit Trail module must be installed and activated. The module is available for Sitefinity Enterprise Edition and records create, update and delete operations for supported content types.

For each content change, keep four pieces of information:

• The agent’s own identity
• The person responsible for the agent
• The request or event that started the run
• The content before and after the change

The before-and-after record matters because an event saying “page updated” can’t restore the previous text. That line is a rumor, not a record. Pair the change record with CMS version history or another tested rollback path, then make sure an editor can use that path without waiting for a developer responsible for the agent.

Decide Which Actions Need Human Review

A suggestion-only agent keeps an editor in control of every change. That is a strong guardrail when the editor can still evaluate each suggestion. The control weakens when suggestion volume turns review into repeated approval with no time to inspect the source, field changes or workflow state.

Set human-review rules by action rather than by whether the tool is called an assistant or an agent. Routine suggestions can stay in the normal editorial queue. Changes to legal copy, pricing, publishing state, templates or large groups of pages should stop for explicit approval. Track queue size and review time so the platform owner can see when the review step has become a click-through exercise. Thirty suggestions approved in four minutes isn’t review; it’s typing practice.

Limit What the Agent Can Read

An agent that only suggests changes still reads content and source material. Its CMS role should limit access to the sites, languages, content types and fields required for the task. If the agent can call external tools through the Model Context Protocol, treat each connected tool and data source as another permission boundary.

Keep restricted drafts, unreleased pricing and internal guidance outside the agent’s readable scope unless the task requires them. For permitted sources, define which source should support each kind of claim and which terminology rules apply. Then test the agent with content it should refuse to read, not only with the clean examples that make for a pleasant demo.

Give Every Check an Owner and a Stop Condition

A checklist nobody owns is a wish list. Each check from the table earlier needs a named owner on both sides, and each one needs a stop action for when it fails. Editors reject a change when fields outside the request changed, the item skipped a workflow stage or the source is unclear. Platform owners withhold or revoke the credential when identity, permissions, source access or change recording fails.

Start with the agents connected to your CMS today. For each one, record its identity, allowed actions, blocked actions, readable sources, change records and required human approvals. If any answer depends on a shared account or an unwritten team habit, the CMS still has a gap in its guardrails, and “someone would probably notice” has never qualified as a control.

Put Your CMS AI Agent Governance to the Test

Before connecting an AI agent to your CMS, make sure the right controls are in place. An agent should have a defined identity, limited permissions, approved sources, traceable changes and clear rules for human oversight.

Use this checklist to review your setup with your platform owner and editorial team:

Image generated with ChatGPT

Review these controls before the agent’s first run and revisit them whenever its responsibilities, integrations or permissions change. If a check fails, address the gap before expanding what the agent can do.

Learn more about Progress Sitefinity CMS and its AI capabilities.

Request a Demo

Applications built over many years can contain extensive business rules, shared procedures and dependencies that are not immediately obvious to someone investigating a problem. AI-assisted development offers another way to explore that complexity. Rather than starting with a blank file, developers can use AI to examine what is already there, ask targeted questions and narrow the search for the cause of an issue.

Why Understanding Existing ABL Code Can Be Difficult

Long-lived OpenEdge applications often reflect years of enhancements, integrations and decisions made by different development teams. A single workflow may span procedures, classes, database queries and application-specific conventions. Documentation may not fully explain why a particular rule exists or which other processes rely on it.

That makes even a seemingly small change an investigation. Developers need to understand not only what a section of code does, but also when it runs, what data it changes and how it interacts with the rest of the application. AI can assist with this initial discovery by explaining code paths, identifying related routines and highlighting assumptions worth checking.

Use AI to Investigate Before Changing Code

One useful starting point is to ask an AI coding assistant to summarize a procedure or class and explain its inputs, outputs and dependencies. From there, developers can ask more specific questions: Where is a field updated? Which routines call this procedure? What conditions determine whether a transaction is committed? These questions turn code comprehension into a focused investigation.

The quality of the results depends on the context available to the assistant. A snippet may explain local behavior, while understanding a complete workflow often requires related files, schema information and project conventions. Developers should treat AI explanations as hypotheses to verify against the actual code, not as a substitute for reviewing how the application executes.

Track Down Difficult Bugs with Better Context

AI can also help when a problem is difficult to reproduce or its cause is not obvious. Instead of asking an assistant to fix a vague error, developers can describe the behavior they observe, the result they expect, the steps that trigger the issue and any relevant logs or code. This gives the assistant a clearer basis for suggesting where to investigate.

For example, if an application returns an unexpected value after a particular update, AI might help trace assignments, review conditional branches or identify code paths that handle the same field differently. The developer can then test those possibilities using existing debugging tools and a reproducible case. This approach is especially useful for narrowing the scope of an investigation before making changes.

Uncover Inherited Business Logic

Not every problem is a technical defect. Sometimes the challenge is understanding a business rule that was implemented years ago and is now buried within application logic. A condition may look unnecessary until a developer discovers that it supports an exception for a particular customer, transaction type or operational process.

AI can help developers trace those rules across related code and formulate questions for the people who know the business. It can surface branches, dependencies and unusual conditions that deserve closer inspection. The important distinction is that AI can help find and explain an apparent rule, but only the organization can confirm whether that rule remains correct and necessary.

Audit Coding and Modernization

Understanding existing behavior is also a practical first step toward modernization. Before refactoring a procedure, replacing an interface or reorganizing a service, teams need to know which behaviors must remain unchanged. AI-assisted code review can help identify duplicated logic, tightly coupled routines and areas where additional tests would reduce risk.

Developers can use the findings to prioritize a manageable sequence of changes. They might first document a complex workflow, add tests around its current behavior and then refactor one component at a time. This makes AI a tool for building confidence in modernization decisions rather than a shortcut that bypasses analysis.

Keep Developers in Control of the Results

AI-generated explanations and fixes still require validation. An assistant may miss a dependency, misunderstand an ABL construct or suggest a change that appears correct in isolation but conflicts with an established business rule. Teams should review suggested edits, test edge cases and check performance and security implications before applying changes to production systems.

A practical workflow is to begin with a specific question, provide only the relevant and approved project context, ask the assistant to explain its reasoning and identify the code involved, then verify the findings with debugging and automated tests. Sensitive source code and data should be handled according to organizational policies and the configuration of the chosen AI service.

Explore AI-Assisted Development with the OpenEdge AI Assistant

AI-assisted development can deliver value long before developers begin writing new features. For organizations maintaining established OpenEdge applications, AI can help developers understand unfamiliar code, investigate difficult problems and uncover business logic that might otherwise take considerable time to trace. Combined with developer expertise, debugging tools and testing, these capabilities can help teams maintain and modernize existing applications with greater confidence.

The goal is not to replace developers' knowledge and experience, but to help them spend less time navigating complex code and more time improving the applications their organizations depend on. To learn how AI can support your ABL development workflows, explore the Progress OpenEdge AI Assistant and discover how AI-assisted tools can help developers work more effectively with existing OpenEdge applications.

Government teams can retrieve information quickly, yet an answer must have clear sources, meaning and permitted use. Records, documents and policies often sit in different systems. As agencies consider AI for work beyond pilots, a reviewer needs a path back to the evidence behind an output. Progress Federal Solutions, is listed as an industry member of the American Council for Technology-Industry Advisory Council (ACT-IAC). ACT-IAC membership creates an opportunity to learn from government priorities and contribute a perspective on mission-ready insight.