If you're on Zoho CRM Enterprise, Ultimate, or Zoho One, you've already got access to Zoho's built-in AI assistant — Zia. Most teams barely touch it.

Zia is Zoho's built-in AI layer. It sits across your CRM data and learns from how your team uses the system — who you contact, when deals move, which emails get replies, and how leads tend to behave before they convert or go cold.

It's not magic, and it won't fix bad data or processes. But when your CRM is reasonably clean and your team is using it consistently, Zia can start doing useful things.

Lead and Deal Scoring

Zia looks at historical patterns and assigns scores to your leads and deals based on how similar ones have behaved in the past. Instead of guessing which leads to prioritise, your team gets a data-backed rank — built from your own CRM history, not generic benchmarks.

Email Intelligence

Zia analyses your sent and received emails and suggests the best time to contact each lead, based on when they've historically opened or replied. It can also flag the sentiment of incoming emails — positive, negative, or neutral — so your team knows the mood before they pick up the phone.

AI for Calls

Zia can transcribe call recordings into text and extract sentiment, intent, and a summary from each conversation. For sales teams making a high volume of calls, this removes the need to take detailed notes during a call and makes it much easier to review what was said and agreed without listening back to recordings.

Ask Zia

Ask Zia is a conversational interface inside your CRM. You can type questions like "show me deals closing this month" or "how many leads came in last week" and get an answer without building a report. It's particularly useful for managers who need quick pipeline visibility and for team members who find report-building slow.

Zia Signals

Zia Signals are notifications that fire when something relevant changes: a lead visits your website, a contact opens an email, or a deal has been sitting in the same stage for too long. They help your team act at the right moment rather than missing it.

Anomaly Detection

Zia monitors your sales metrics and flags when something looks unusual — a drop in calls made, a spike in deals lost, a change in conversion rates. It won't tell you why, but it will tell you that something has shifted, which gives you the chance to investigate before it becomes a bigger problem.

Smart Prompts and AI-Assisted Setup

Inside any CRM record, Zia's Smart Prompts give you a Record Assistant — a summary of your full conversation history with that contact, recent activity, and current status, without clicking through multiple tabs. You can also use it to draft personalised emails from the record directly. Beyond day-to-day use, Zia can create modules, workflows, and reports from plain-English descriptions, which cuts down the time spent in setup screens considerably.

None of this requires you to build anything from scratch. Zia uses the data you're already collecting in Zoho CRM.

There's also a newer layer worth knowing about: Zia Agents — autonomous AI agents that can execute tasks across your CRM without manual prompting. These sit beyond the scope of this article, but if you've got the basics running well and want to go further, agents are the natural next step.

This isn't about rushing through. It's a structured week that builds in the right order — each day's work sets up the next — so by the end you've got Zia switched on, you know how to use it, and the whole thing fits into how you already work.

The same structure can be applied to other CRM platforms — HubSpot, Pipedrive, NetSuite — but as a Zoho Authorised Partner of 10 years + its where most of the businesses I work with start.

Day 1 — Data Health Check

Zia won't give you useful predictions from messy data.Before anything else, you review your current records: missing fields, duplicate contacts, inconsistent lead stages, incomplete deals. A few hours here saves a lot of frustration later, and it often improves the CRM generally, not just for Zia.

Day 2 — Email Intelligence

Connect your email and turn on Zia's email analysis. Start seeing sentiment flags and best-time-to-contact suggestions for your key contacts. This is often the feature that gets the most immediate positive response from sales teams — it's visible and immediately useful.

Day 3 — Ask Zia

Set up and test the conversational query tool. Work out which questions your team asks most often and make sure Zia can answer them. This gets people comfortable talking to the system rather than just clicking through menus — a shift that tends to stick.

Day 4 — Predictions and Scoring

Review your historical data,configure Zia Predictions for leads or deals, and make sure your stages and fields are set up in a way that gives Zia something useful to work with. This is where the data work from Day 1 pays off.

Day 5 — Zia Signals and Notifications

Configure which signals matter for your business. Not every notification is relevant — the goal is useful alerts, not noise. Set up the ones that match how your team actually works.

Day 6 — Use Workqueue or Custom Views and Focus Lists

Build views that help you or your team make best use of Zia. Your team shouldn't have to go looking for AI insights — they should see them as part of their normal daily view of their specific pipeline or work area.

Day 7 — Develop a Daily Routine and Review with AI

Pull everything together into a simple daily habit:check Ask Zia for a quick briefing, work the priority list, process signals, review the week. Make sure your team knows what to do and feels confident doing it.

By the end of the week, you will have Zia switched on and connected to your data in a way that starts to work with your business. 

The aim is:

• A cleaner, more consistent CRM that Zia can learn from and help you with your daily crm use.
• Email intelligence, Signals, and predictions feeding into one or two daily views instead of being buried in settings menus.
• A working setup with a daily routine that uses it without adding extra too much in extra admin or cost!.

Try and  end up with a daily CRM check that takes 10 to 10 minutes instead of an hour of clicking around and exporting spreadsheets.

Now I know this  won't transform your business overnight, but its a good start to use AI that may already be included in the Zoho CRM subscription you pay for. It can help form part of wider plans for automating or improving areas of your business operations. But it will give you a more informed view of your pipeline, save your team time on manual checks, and start surfacing the kind of patterns that are easy to miss when you're moving quickly.

No restore test has ever been run.

The backup runs daily, but no one has checked whether the output can actually be used to restore records into the live system. This is the single most common gap I find.

No one knows who can delete data — or who has.

Access controls are often set up at implementation and never reviewed. By the time a problem occurs, it can be genuinely difficult to trace what happened and who did it.

There is no independent copy.

The backup exists, but it is stored inside the same platform or account. A separate external copy is what gives you a genuine safety net.

No one is specifically responsible for checking it.

Backups are set up once and then forgotten. Without a regular check — even monthly — a silently failing backup job can go unnoticed until the moment you need it most.

There is no plan for recovery.

Even businesses with solid backups can lose significant time in a data loss event if no one has thought through who does what, in what order, and how long it should take.

Don't Overestimate Your Existing Data Suitability

A successful manufacturing company got bought out. They needed to move from Sage 50 to Sage X3.

Everyone thought it'd be dead simple. Two to Three Months months, max. Same software family, right?

Business was doing well, so the data must be fine.

Wrong on all counts!

My Job: Making the Data Actually Work

I got brought in as the ETL consultant. That's Extract, Transform, Load - basically, I take messy data from old systems and make it work properly in new ones.

The parent company had their Sage X3 technical team sorted. But they needed someone to handle all the data work - extracting it, cleaning it up, and getting it ready for the new system.

The client's assumption was understandable - same software family, successful business.

But from experience I knew better than to take that at face value. I always use a systematic approach - my own Flow7 method which I apply to data migrations, reporting and AI.

The Reality Check: What I Found

I always start with a proper assessment. You can't fix what you don't understand.

When I dug into their systems, here's what I found:

• Product recipes and assembly instructions? Lived in one person's head, not in any system
• Stock levels in Sage 50 didn't match what was actually in the warehouse
• Processes had grown organically over years with zero documentation
• New products got added daily with just the bare minimum info
• Working remotely via their VPN was painfully slow

Not exactly migration-ready!

Data Assessment Time

Once I extracted the initial data, the real picture emerged:

Product Data Problems:

• 7,000+ product records that needed serious clean-up
• No product assembly instructions for (BOMs) at all
• Different product types missing crucial data
• Critical knowledge trapped in a few long-term employees' heads

Missing Information:

• Sage X3 required loads of data that Sage 50 simply didn't track
• No recorded warehouse locations in Sage50
• Sales orders and Purchase orders with random text instead of proper product codes

...and that is just for starters!

The Killer: Most of this wasn't just data cleaning. It needed people to create entirely new information from scratch.

Building a Workable Data Master & Clean-up Solution

I needed a controlled way to manage all this data. Here's what I was up against:

• Problem 1: Couldn't get a stable live connection to their Sage 50 due to IT constraints - I work remote and they were hours from me.
• Problem 2: Needed loads of new data that didn't exist anywhere in the companies processes.
• Problem 3: Who was going to create all this missing data?
• Problem 4: New data had to integrate with parent company's existing live system from day one.
• Problem 5: All imports had to be done manually (no "press of a button" solution as often assumed by clients!)

My Basic Solution: The SQL Master Set

I set up a local SQL database to manage everything. Not the fanciest solution, but it worked, I like using SQL so there it is!

I could have used two other low cost tools that I also like, Skyvia or ZOHO Dataprep.

Here's how I did it:

• Loaded Sage 50 backup into a local copy of Sage 50 on my development PC
• Extracted data tables from Sage50 via Excel (my "SQLLINK" file)
• Imported everything into SQL with proper checks
• Created new data Excel data collection files with clear rules that were added to the partner company sharepoint storage.
• Built SQL views to output data matching Sage X3 template requirements

Caution: The team didn't always follow my rules for the new data files, but that's people for you!

Understanding Sage X3's Requirements

Lucky for me, I'd worked with the parent company before. I knew their Sage X3 setup and had a good grasp of how the data structures worked.

Also the project was being delivered by an implementation partner that needed to move through tasks in their own project plan; they were always only too happy to support the data, process or field checking queries when raised by me, these were timely and on point. It was good working with them. No messing, no fuss.

I created basic mapping templates using the base Sage X3 Excel Templates that implementation partner provided. This became my starting point for the mapping & transformation work.

This is my favourite bit. Taking messy, scattered data and making it work properly.

Sage X3 was completely different from their simple Sage 50 setup. I needed to:

• Restructure product info for X3's complex requirements
• Create data, fields and categories that didn't exist in Sage 50
• Convert informal knowledge into proper structured records

I used Excel for high-level mapping (why not?). It was perfect for discussing details with the Sage 50 team and they were using that daily anyway. Column B is my S50 tables/master data set and Column K is from X3.

Then I transferred everything to SQL views.

My ETL structure in SQL:

• Source views (from Sage 50 tables)
• Transformation source and combined views (where the cleaning happens)
• Output views (that match import template requirements)

Basic data architecture. It works for me. There are other data architectures, but for this type of work this principle just works.

The Timeline Reality Check

Original plan: 2 to 3 months (before any proper assessment!)

My analysis: Completely unrealistic. Despite the Source not being a large data set, it was very lacking in information for Sage X3

The Real Work Required:

• 7,500+ product records needing individual attention
• 1,500+ assembly instructions to create from scratch
• Hundreds of new data fields for processes that didn't exist in Sage 50
• Warehouse and manufacturing rules living in people's heads
• Thousands of purchase/sales orders needing clean-up
• Customer and supplier records too!

More Realistic Timeline: 5 months minimum. Driven by new data creation, not technical complexity.

Caution: The management team was sceptical about the timeline and data state - why wouldn't they be, it's natural.

So I ran tests to show exactly how long the cleaning actually took by the staff doing it and they flagged completed SKUs as they went.. providing an easy checking number.

It helped the staff as well, because they all had day jobs to fit around the data cleaning work.

The Numbers don't lie. This became a resource and knowledge issue - that then affected my own ETL timelines and the data migration project as a whole.

Early testing is crucial. I always test the import templates first - make sure they actually work with every data set.

Key things to know:

• Once records are in Sage X3, they get new IDs - map these to the unique IDs in the source system.
• Need unique identifiers from the old system for updates - create your own don't rely on e.g. Product skus or Customer numbers despite them appearing as unique.
• Sage X3 error checking can be a nightmare during go-live so head this off early!
• Expect Iteration between testing and final data requirements

I create my own personal Data Loading Plan and tested it multiple times as we went through DEV and UAT testing Sandboxes that were invaluable. When stakeholders want updates, they need to understand the time it takes and process - remind them, they do forget and will question the loading times. Although the data loading tests were a moving target the total load time could be estimated quite accurately. ETL can be iterative by nature so if you follow a similar approach to Flow7 you may reassess new data, then add or combine in the master data set to then feed through to testing.

The GUI in SAGE X3 was limited to 1000 records display so it was better to chunk up data for error checking.

Pro tip: Get access to the front-end system. You need to see what users see.

Go Live: The Final Push

The company chose a full cutover over a long weekend. Stop the old system, start processing in the new one, that was live already for the parent. There products were structured very differently from the new subsidiary.

As soon as they downed tools in Sage 50, I get to work with my plan to hand.

My example Loading Order (this matters in Sage X3 and sometimes comprises multiple imports for each):

0. Suppliers/Contacts
1. Customers/Addresses/Contacts
2. Products main record
3. Supplier Products
4. Customer Loan products
5. Locations
6. Product sites
7. Product costing
8. BOMs (4 different types)
9. Work centres/operations
10. Purchase Orders
11. Sales Orders
12. Stock receipts
13. Financial data

Data loading can depend on fields or values in previous data, so this may have to be exported back to the master set, as part of the load process An example is the Supplier Ids from SAGE X3 to prepopulate Supplier Products.

Caution: Make sure to align record counts with the business team that you are importing. This is one key check for me and I often repeat it, during the project like a stuck record (so I've been told, I'm the same with Backups of the data!)

During the go live loading, different team members are waiting on the data to populate to start running their checks and tests. Whether, you the business, are managing the Go Live Data Plan or your implementation partner it's a crucial time. Your team needs to be fully informed and are crucial to the success of your data migration project.

Key Lessons for Your Next Migration

1. Never Accept Data Assumptions - Have a look!

2. Get An Idea of Precise Data Counts and Metrics
By providing precise quantities of work required, you can help stakeholders allocate resources properly and set realistic expectations.

3. Design for Business Continuity
A structured approach lets complex data work happen without disrupting daily business operations.

4. Test and test again
By identifying issues during Development and UAT in the TARGET system, you prevent nasty surprises during go-live.

Red Flags for Data Migration

Complex Data Situations:

• Data scattered across multiple systems
• Inconsistent formats and quality
• Legacy systems with years of problems

System Transformation Projects:

• Moving from simple to sophisticated systems
• Company mergers needing data consolidation
• Any situation where "it should be straightforward"

Time and Budget Pressure:

• Unrealistic stakeholder expectations
• Need to prove real scope of work
• Can't afford to get it wrong

I Hope You Gained a Few Helpful Pointers For Your Next Migration Project

I hope this case study demonstrates why not to overestimate your data suitability before you have a good look at it.

Start with a thorough assessment - Surface-level assumptions about data quality are usually wrong.

For your next migration project, especially in acquisition scenarios: invest time upfront to understand the true data picture before committing to timelines and budgets.

Plan for business continuity - Phased approaches can keep operations running during migrations

Test everything systematically - Proper testing prevents go-live disasters

The lesson here isn't about just assuming the data is okay - it's about having a proven process to identify what you're really dealing with.

Why It's Important to Understand Your Data Sources in a Data Migration

You're finally ready to upgrade that ancient system that's been holding your business back. The new software looks brilliant. The demos went well. Everyone's excited about the possibilities.

But here's what nobody tells you: "64% of data migrations overrun their forecast budget, with 54% overrunning on time," according to Forbes research [1]. McKinsey studies echo this challenge, finding that "75% of cloud migrations ran over budget, while 37% ran behind schedule" [2].

I've seen this pattern repeatedly myself. A small business owner calls me months into what should've been a straightforward project. They're stressed, over budget, and their team is losing faith fast.

"We thought we knew our data," they always say. "It seemed so straightforward. Can you help with our data?"

That's the thing, though. It never is if not planned and assessed and the team is on board.

The Costly Mistake Pattern I See Repeatedly

Here's a scenario that plays out more often than you'd think. Imagine a 45-person manufacturing business planning a system upgrade. Budget approved. New software chosen. Timeline set.

Two weeks in, the project grinds to a halt.

Why? They've discovered a critical inventory tracking system nobody mentioned in the planning meetings. An old Access database the warehouse team had been using for years to track special orders.

The "simple" migration becomes a nightmare. E.g. What started as an £8,000 budget project balloons to £20,000 plus with extra resources required.

But here's the thing: it was completely avoidable.

This is exactly why I use and developed the Flow 7 Migration System. And it all starts with Step 1: Know Your Data Sources.

Because you can't successfully migrate what you don't fully understand.

The Hidden Complexity Trap

Data migration looks simple on the surface. Move data from System A to System B. Job done.

But underneath that simplicity lies a web of complications that can derail even the best-planned projects.

The biggest trap? Assuming you know all your data sources.

Example Scenario: The Medical Practice That Nearly Lost Patient Data

Imagine a small medical practice upgrading their patient management system. Initially, they think they only had one data source: their main practice software.

Digging deeper reveals:

• A separate appointment booking system
• Excel spreadsheets with specialist patient notes
• A standalone billing system
• Scanned documents in a different file system
• Historical records in an old database nobody used anymore

What looked like a simple one-to-one migration became a five-source juggling act. The complexity doesn't just double—it multiplies exponentially.

Why Every Extra Data Source Multiplies Your Risk

Here's something most people don't realise: migration complexity doesn't increase linearly. It's exponential.

• One source = more straightforward *subject to other data assessments
• Two sources = manageable *
• Three sources = getting tricky *
• Four or more sources = and so on!

Each additional source brings:

• Different extraction methods
• Unique data formats
• Separate quality issues
• Individual technical challenges

This is why Step 1 of the Flow 7 system focuses entirely on tracking down every single data source before you start getting into moving the actual data.

Three Critical Questions You Must Answer

In my experience working with small businesses, I've identified three make-or-break questions that determine migration success:

Question 1: How Many Data Sources Do We Actually Have?

This sounds obvious, but it's where most projects go wrong.

You need to dig beyond the obvious systems. Create a simple inventory that includes:

• Main business systems (obviously)
• Departmental spreadsheets
• Legacy systems you rarely use
• Personal data stores on individual computers
• Paper records that might need digitising
• Backup files with historical data

Pro tip: Don't just ask management. Your receptionist might maintain customer notes in a separate system. Your sales team might have lead data in spreadsheets nobody else knows about.

Question 2: What Types of Systems Are We Dealing With?

Not all databases or data sources are created equal. Each system type needs a different approach:

• Traditional databases (SQL Server, MySQL) usually have decent export tools but might have complex relationships hiding in the background.
• Cloud applications often limit how much data you can extract at once. Some have proper APIs, others make you jump through hoops.
• Accounting systems like QuickBooks or Sage often need special connectors. You can't just export everything as a CSV and hope for the best.
• Spreadsheets are the wild west of data. Hidden formulas, manual corrections, inconsistent formats—they're migration nightmares waiting to happen.

Question 3: What Exactly Are We Working With?

Generic descriptions don't cut it. "Our CRM system" or "the accounting database" aren't specific enough. You need exact names and versions. Here's why:

Hypothetical scenario: A business tells me they're using "Microsoft Dynamics." Sounds straightforward, right?

Turns out they're running a heavily customised version of Dynamics NAV 2013. That's a completely different beast from current versions. Standard migration tools won't work. Custom scripts needed. Timeline extended.

If this was discovered mid-migration instead of during planning, it would be a potential disaster.

The Human Side of Data Migration - It's CRUCIAL!

Technical understanding is IMPORTANT, but there's another layer most people miss: the human element. This is crucial.

Who Really Knows Your Data?

The person who manages the databases or software might not understand what all the fields mean and what your business processes involve. You need the people who use it every day.

Case Study: Quite a few years ago on a large NetSuite Data migration for a retail seed company I was involved with, I had many days onsite, this was before remote work was the norm, and it taught me how valuable the Team were from all areas and be able to identify them. Their day to day knowledge can highlight so, so much and I can't elaborate enough that having access to these people as a key resource can save hours in a project. I'd like to list and thank them...but for data privacy I cannot, but if they are reading this (doubtful) you know who you are!

For each data source, identify:

• Who "owns" that data
• Who uses it daily and who knows about the processes
• Who understands the quirks and workarounds
• What unofficial systems exist to fill gaps

The Reality of Data Quality

Every business has messy (or missing data). The trick is knowing about it upfront rather than discovering it mid-migration. This is Step 2 of the framework.

A manufacturing company not only had very limited records in their source system, but were missing a huge amount of data. This impacted their timeline significantly during the migration project.

Your Step-by-Step Investigation Plan

Here's the simple approach I recommend. It takes about half a day but can save you significant problems down the line:

Step 1: Hold a Data Discovery Workshop
Get your key team members together for two hours. List every system anyone uses to record or access business data. Don't assume management knows everything—frontline staff often create their own solutions.

Step 2: Document What You Find
Create a simple spreadsheet with:

• System names and exact versions
• What data each contains
• Who uses it most
• How you currently get data out

Step 3: Identify Your Data Experts
Note who understands each system's quirks and nuances. These people are gold during migration.

Step 4: Sample Your Data Quality
Look at 10-20 random records in each system. Spot potential issues whilst they're still easy to fix.

Step 5: Map the Connections
Sketch how data flows between systems. Understanding these relationships prevents nasty surprises.

Step 6: Test Data Extraction
Try exporting data from each system. See what you get and what might be missing.

The Cost of Getting It Wrong

Small businesses often rush this investigation phase. They're eager to show progress by jumping straight into migration.

When you miss a data source mid-migration, you face:

• Reworking completed migration code
• Extended timelines and increased costs
• Team morale problems
• Potential business disruptions

The ROI of Doing It Right

Proper source investigation might seem like unnecessary delay, but in my experience, it can significantly reduce overall project time.

More importantly, it ensures your team finds reliable, complete data in the new system—data that supports your business instead of creating new problems.

Why the Flow 7 System Works For Me

I apply the Flow 7 Migration System to data migration work I undertake. Understanding my client data sources first for any data movement - be it; migrations, reporting, automations or AI data flow.

It's Step 1 for a reason.

You can't plan a successful migration without knowing:

• How many sources you're dealing with
• What types of systems they are
• The specific technical details of each

The businesses that succeed with migrations are the ones that invest time upfront in understanding what they're working with rather than just assume.

Your Next Step

If you're planning a data migration, don't make the same mistake that leads 64% of projects to go over budget. Don't assume you know your data.

Start with a proper investigation. Map every source. Understand what you're working with.

It's not the exciting part of migration, but it's the part that determines whether your project gets off on the right footing or joins the failure statistics.

Ready to get started? Check out Step 1 of the Flow 7 Migration System for an easy to follow data migration project approach.

Because the difference between migration success and costly failure often comes down to what you discover in the first few days—not the last few weeks - when it's too late.

Four valuable steps I've found from building custom X3 views that actually work

I've built dozens of custom views in Sage X3 over the years. I'm not a Sage X3 consultant, but I have worked extensively with the X3 data. And I've learnt something that might surprise you: the best Sage X3 views I've found aren't built in Sage X3 to start!

They're built in SQL Server Management Studio first - well that's my view (lol) as a data person rather than an X3 consultant that may work it differently.

Here's why that matters, and the four steps that'll potentially save you hours of frustration. But will also save development time and cost.

The Problem with Going Straight to X3

I get it, you have been asked for a query in Sage X3 and the team needs a new, possibly complicated Sage X3 View to feed into the SEI and naturally it feels right to dive straight into Sage's SQL query area. In my experience this can be a mistake.

SQL inside X3 doesn't always behave like normal SQL Server. It's got quirks. Limitations. Things that work perfectly in SSMS can throw errors or return wrong data in X3 adding to frustrations and time. These differences mean writing queries in Sage X3 might feel restrictive compared to regular SQL Server, especially for users that are used to using SQL in SQL Server Management Studio (SSMS) and expecting full SQL Server features.

Yes, maybe I'm biased, and set in my ways; I like using SSMS and it's a first choice if available for SQL. I apply simple frameworks to my data work. So my personal approach, developed over the years, regardless of simple or complicated views is four fold:

1. Get a clear plain English (or other language!) explanation of what is needed from the user/client.
2. Get to that Data output using SSMS first.
3. Translate that into SAGE X3 SQL query or queries.
4. Create the SAGE X3 VIEW(S)

Step 1: Start with Plain English or other language! (Seriously)

Before I touch any code, I get the user to explain exactly what they want in plain English, i.e. a very clear plain description with no jargon of what they need. If a term or process is not clear I get it explained. Also get them to show you where any related information sits in the system that they currently use, if at all.

Not "I need sales data with customer information." That's too vague.

I want: "Show me all invoices from the last 6 months, grouped by customer, from sales region X with their total spend and average order value, and outstanding balances."

This sounds obvious, but you'd be amazed how often requirements change once you pin them down. Better to catch this early than rebuild a view three times. If they do change you have an audit trail!

My tip: I actually write this requirement at the top of my SQL file as a comment. Keeps me focused when the query gets complex. I find my comments help, be it block or line comments.

/** Show me XYZ - SPDATA - 23/7/25 **/

Step 2: Build and Perfect in SSMS

This is where the data gets found and sorted…like magic - not quite it's feedback and getting to the bottom of the user request.

I connect SSMS directly to the Sage X3 database and build the view there. No X3 interface. No limitations. Just pure SQL.

My Tip: I like to create views into the core tables and use those views as the first building blocks. I then create sub or source views, that do the work and that build the picture of what I need and then roll these up into final OUTPUT views. It's a simple data structure using the Medallion Architecture principle, which uses Bronze, Silver, Gold. This works for me!

• Bronze = Raw data
• Silver = Source Views (with transformations and calculations)
• Gold = Final Output

X3 TABLE VIEW > SOURCE VIEWS > OUTPUT

CREATE VIEW view_X3_TABLE AS SELECT * FROM [SERVERIP].[sagex3].[LIVE].[TABLE]

Here's my process:

• Start simple with the core tables I need from X3
• Add JOINs one at a time from my source views
• Test the data at each step
• Create output views
• Check the results with the client before moving on…

My Tip: Game changer: I always ensure I have front-end user access to Sage X3 during this stage. Being able to navigate the actual screens, look-up fields, and see how data flows through the system is invaluable. The more I work with a client's operations through the UI, the better I get at nailing the right data in SSMS without bothering them with basic questions.

Very Important caveat: SSMS bypasses all of Sage's business logic, validation rules, and data transformations. The raw data you see might not match what appears in Sage X3 screens. This is why having UI access helps - you can cross-reference what you're building against what users actually see and adapt views to support any logic. Depending on what you are looking for, your users may see data in the UI but it doesn't exist anywhere in the database tables or views - that's for another day - hint: SAGE X3 FUNCTIONS.

The key is getting the data structure and relationships right in SSMS. Don't worry about X3 compatibility yet. Just focus on pulling the correct raw data.

I'll run sample queries, export small datasets, and verify everything myself and with the client. "Does this look right? Are these the customers you expected? Do these totals make sense compared to what you see in Sage?"

This back-and-forth is crucial. Data that looks correct to me might reveal edge cases the client knows about.

Step 3: Translate to X3 SQL QUERIES (Expect Surprises)

Now comes the tricky part: making it work in Sage X3.

I copy my working SSMS queries into X3's SQL query area. And almost always, if you start with the OUTPUT query it will error on the first go!

My Tip: As I use source queries, these need to be replicated first so; run each in SQL Query, then create the VIEW for the sub or source query in STEP4. Then rewrite the OUTPUT queries to read the source VIEW you created within X3. Yes you could have a monster view but I prefer the source join structure I have used over many years as it's easier to replace elements if iterations are required.

This is where core differences can come into play also. Note these may be issues and error checking in X3 is fun…NOT!!

• Rewrite CTEs as subqueries or stored procedures
• Change parameter syntax from @param to %1%
• Restructure JOINs to avoid row size limits

I test the X3 SQL version against my SSMS results, understanding that some differences might be due to business logic that X3 applies but SSMS doesn't. This logic may need building into your source views once it can be defined.

Step 4: Create the X3 SQL Views

Once the SQL query works in X3 and the client confirms the data looks right, then I create the actual internal views. This becomes available to SEI dashboards and reports.

But I still cross-check the final view output. Trust and verify.

X3 Tip: A common tip for SAGE X3 is when creating custom records prefix with Z so e.g. your view in SSMS might be v_OUT_CUSTSALES_V1 in sage x3 it's ZCUSTSALESV1

My Tip: Version control all views!

Why This Approach Works For Me

Four reasons this method saves time for me:

Faster debugging: SSMS has better error messages and debugging tools than X3.

Client confidence: They can see the data structure and relationships before it's locked into X3, even if the final numbers might differ due to business logic that has been identified and accounted for.

Future maintenance: I've got a working SSMS version I can quickly modify/test without needing to touch X3 first when requirements change.

Back-up set: I take backups of all the stages but the most important for me is the SQL version.

Some Key Differences To Be Aware Of: Sage X3 SQL vs Standard SQL Server

Here are SOME differences you may encounter or be aware of:

• Business Logic Focus: Sage X3 SQL queries are meant to pull data for business reports and screens, not for general database tasks.
• Complex Queries Limited: Certain advanced query features (like Common Table Expressions—CTEs using WITH) don't work in Sage X3; workarounds like stored procedures may be required.
• Automatic Query Hints: Sage X3 can automatically add an "OPTION (FAST 1)" optimisation hint to queries, which changes how results are fetched. This can be changed or turned off by settings in Sage.
• Parameter Format Is Different: Instead of @parameter, Sage X3 uses %1%, %2%, etc., for query parameters (placeholders for filters/values).
• Row Size Errors: It's easy to hit the Microsoft SQL Server row size limit (8,060 bytes) in Sage X3, especially when making queries that join many tables or include lots of fields. This can cause errors that might not appear in standard SQL tools.
• Doesn't Support All SQL: Some complex queries that run fine in SQL Server Management Studio (SSMS) may fail or not be allowed in Sage X3's SQL query requester.
• Security Filters Are Skipped: Custom SQL queries in Sage X3 can bypass normal role-based or site-based security, showing data that might otherwise be hidden in regular screens.

These differences mean writing queries in Sage X3 might feel restrictive compared to regular SQL Server, especially for advanced users expecting full SQL Server features.

The Bottom Line

Building Sage X3 views isn't just about knowing SQL. It's about understanding the user requirements and that X3 has its own personality and business logic layer.

Start in SSMS where you can work fast and debug easily. Get the data structure right. Know the data, know the business processes and what the target output required is. Then carefully translate/map to X3, accounting for business logic differences.

You or your clients will get exactly what they asked for. And you'll avoid those 2am debugging sessions wondering why perfectly good SQL isn't working.

That's a win for everyone.