Microsoft Syntex – the well-loved SharePoint Pay-As-You-Go (PAYG) services exposed a set of discrete document processing meters (Autofill columns, Unstructured, Prebuilt, etc.) that were billed through an attached Azure subscription. Each unit of work, such as a page, image, or character, was charged according to the meter-specific unit price defined in the PAYG pricing model.
AI in SharePoint introduces a new experience layer on top of these content services, embedding AI directly into SharePoint UX (floating AI button, agents, and skills) and making content Copilot-ready. While the consumption-based meters continue to exist (unfortunately, that brings a lot of confusion) behind the scenes as part of Pay-As-You-Go services, the primary entry point for end users is now conversational and intent-based rather than feature-by-feature configuration.
Under the covers, AI in SharePoint still relies on the same underlying content processing primitives that originated in Syntex (OCR, classification, extraction, translation, content assembly, and so on). However, these capabilities are now surfaced through higher-level constructs such as agents and AI skills and are governed by Copilot licensing for interactive experiences, with pay-as-you-go meters remaining the scaling and cost-control mechanism for high-volume content processing.
If you haven’t heard about my blog post: please have a read here: https://gokan.studio/2025/11/17/pay-as-you-go-is-dead-long-live-seat-based-licensing-again-for-sharepoint-ai/
One-To-One Mapping
Many have been asking, and the following table provides a one-to-one mapping of Syntex PAYG meters to their closest equivalents or successors in the AI in SharePoint world. The mapping is organized by the original Syntex service, its legacy behavior, the modern AI in SharePoint or Content AI equivalent, and practical notes for architects and administrators.
| Syntex PAYG service | Legacy function | AI in SharePoint | Internal Notes | AI Notes |
| Autofill columns | Extracts metadata and populates library columns using AI models; billed per page/sheet/slide/file transaction. | “Create autofill columns” in AI in SharePoint libraries, backed by Copilot | Functional behavior is almost 1:1. The configuration UX moves from Syntex model galleries to AI in SharePoint actions. | Merged (FAB) + Autofill + Skills |
| Document translation | Translates document content; billed per processed character. | Content AI document and video translation, plus Copilot rewrite/translation experiences. | High-volume translation still uses PAYG meters, but ad-hoc translation is typically initiated via AI in SharePoint or Copilot experiences. | Not Merged |
| eSignature | Sends eSignature requests; billed per signature request (up to a fixed number of recipients). | SharePoint AI eSignature integrations, orchestrated with Power Automate and AI in SharePoint skills. | The core signing service remains unchanged; AI in SharePoint and skills act as an orchestration and initiation layer over existing flows. | Not Merged |
| Optical character recognition (OCR) | Extracts text from images and scanned documents; billed per page or embedded image transaction. | Foundational OCR in Content is used implicitly by SharePoint AI to make content AI-ready. | OCR is still needed on the Purview side, and AI in SharePoint requires user intervention while OCR is always on. Enabling AI in SharePoint does not automatically process the file. | Merged (Backend) + Autofill |
| Content assembly | Generates documents from templates; billed per generated document (automated generation always billed). | Template-driven document assembly in Content AI combined with Copilot-driven content generation. | Deterministic document generation remains template-based with Lists, Metadata and free text | Merged – Document Generation Form |
| Image tagging | Automatically tags images with AI-generated metadata; billed per image processed. | AI-ready content auto-tagging surfaced as better search, discovery, and Copilot grounding in SharePoint. | Image Tagging is no longer configured as a standalone feature; it becomes a background enrichment step. Value is realized through improved search relevance and AI answers rather than explicit Syntex configuration. | Merged (Backend) + Autofill +Skills |
| Taxonomy tagging | Automatically applies managed metadata terms; billed per document processed. | AI in SharePoint site-improvement and governance skills that apply and remediate metadata. | Managed metadata auto-application continues, with AI in SharePoint providing holistic site-level views for missing/inconsistent metadata and governance operations. | Skills Match against MMD — Use get_taxonomy_info with the termSetId, and sspId from the term set. |
| Prebuilt document processing | Uses pre-trained models (invoices, receipts, IDs, simple documents); billed per processed page. | Models are used by AI in SharePoint library actions, such as “Create autofill columns”. | Model set continues to expand (for example, simple document processing). Invocation shifts from explicit Syntex configuration to AI-driven actions and workflows. | Merged (FAB) + Autofill + Skills |
| Structured and freeform document processing | AI Builder-backed models for structured forms and semi-structured documents; billed per processed page. | Content AI structured/freeform models consumed by AI in SharePoint Autofill Columns and skills. | Model lifecycle (train, test, publish) remains in AI Builder/Content AI; AI in SharePoint acts as a consumer and orchestrator at the library or site scope. | Merged (FAB) + Autofill + Skills |
| Unstructured document processing | Syntex content understanding models that classify and extract metadata from general documents; billed per page/sheet/slide/file. | AI in SharePoint file- and site-level experiences such as “Ask about this file”, “Summarize“, “Generate FAQs“, and comparison across documents. | Unstructured understanding moves from explicitly activated Syntex models to implicit content understanding underpinning conversational and skill-driven actions. | Merged (FAB) + Autofill + Skills |
1 – Autofill Columns
In Microsoft Syntex, Autofill columns counted one transaction per processed page, sheet, slide, or file, and populated library columns using AI-extracted values from bound Syntex models. Model configuration typically occurred at the library level, with explicit association between a content type or library and a Syntex model.
In AI in SharePoint, the same underlying behavior is exposed through the “Create autofill columns” experience in document libraries. SharePoint AI remains responsible for the actual extraction, but end users interact with a higher-level AI action rather than a Syntex-specific configuration UI. From an architecture standpoint, the libraries that previously relied on Syntex models become smart libraries that can also be queried, summarized, and automated via AI in SharePoint and Copilot.
Autofill’s biggest drawbacks
1. Not Reusable Across Libraries – Autofill configurations live in your document library. You can’t reuse them in another library. Each library requires its own separate setup—no sharing, no inheritance.
2. Testing Limited to One File at a Time – You can only test your prompt on a single file. With multiple thousands of files? You’re flying blind. No way to validate behavior at scale before hitting production.
3. No Preview Pane for Batch Testing – When you run batch prompt testing, there’s no preview of what’s actually happening. You submit the batch and hope it works. No visibility into errors or extraction quality until it’s too late.
Biggest Strength
1. It’s Easy – Just Ask – Turn it on, it works. No library binding, no model galleries, no complex setup, no refiners, no extractors. Users just ask Copilot to fill columns.
2. Add Extra Logic in the Prompt – You’re not limited to simple extraction. Ask Copilot to transform the data as it fills: “add 20% VAT to prices” or “append the country code to addresses.” The prompt itself becomes your logic layer.
2 – Document Translation
Document translation in Syntex PAYG is metered per character processed and applies machine translation over the content of supported file types. It is primarily targeted at high-volume, back-office translation scenarios, often invoked from Power Automate or custom services.
In the AI in SharePoint era, translation remains a metered content service in Content AI, while AI in SharePoint and Copilot provide conversational entry points for rewrite and translation tasks. Architects can continue to use the PAYG translation meter for large-scale, scheduled workloads, while users can leverage Copilot experiences for ad hoc or interactive multilingual authoring (translation will fail, but summary will succeed ☺️)
3 – eSignature
The eSignature meter in PAYG counts each signature request (up to a fixed number of recipients) and is typically used with Power Automate to orchestrate document routing, approvals, and signing. The integration with third-party eSignature providers is managed via connectors and actions.
In AI in SharePoint, the eSignature capability is still delivered via PAYG services and underlying provider integrations, but AI in SharePoint and custom skills can now drive orchestration. A skill can encapsulate an end-to-end workflow (prepare document, send for signature, archive the signed copy) and is stored as a Markdown definition in the site’s Agent Assets library, allowing natural-language initiation and reuse across the site.
4 – Optical Character Recognition (OCR)
In Syntex PAYG, OCR is explicitly metered per page or per embedded image and is triggered whenever content is uploaded or updated in libraries where OCR-based processing is enabled. The extracted text feeds into both search and downstream AI models (structured/freeform/unstructured).
In AI in SharePoint, OCR becomes part of the baseline “AI-ready content” pipeline. Administrators do not enable a separate OCR feature; instead, enabling AI in SharePoint and Content AI ensures that non-text-native documents (scans, images, photographs) can be processed on demand when users initiate interactions, rather than automatically, so that Copilot and agents can answer questions, summarize, and compare content across a site.
5 – Content Assembly
Content assembly in Syntex PAYG generates documents from templates and is billed per generated document when the generation is automated. This model is well-suited for deterministic outputs such as contracts, NDAs, and formal communications where structure and wording must adhere to strict templates. With AI in SharePoint, template-based workflows have shifted to generate structured documents in a SharePoint document library
6 – Image and Taxonomy Tagging
Image tagging and taxonomy tagging meters in Syntex PAYG are charged per image or document when these enrichment features are turned on for a library. They drive auto-population of metadata that improves search, filtering, and compliance.
In AI in SharePoint, these enrichment steps are internalized into the broader “AI-ready content” concept. Images can be tagged via autofill, enabling discovery based on recognized objects and concepts, and metadata seems not to be taken into consideration yet. Today, Skills seems to be the best option.
7 – Prebuilt, Structured/Freeform, and Unstructured Models
Syntex PAYG exposes several model families: prebuilt models for common document types (invoices, receipts, IDs), structured and freeform models backed by AI Builder for forms and semi-structured documents, and unstructured content understanding models that learn from examples. All of these are metered per processed page or equivalent unit and can be bound to libraries or content types.
| There is no native ability to perform sensitivity and retention labeling with AI in SharePoint, and this is a gap. |
In AI in SharePoint, these models form the processing substrate for higher-level experiences. Library automation features like “Create autofill columns,” and site-level AI actions use these models under the hood, while conversational features such as “Ask about this file, “Summarize,” or “Generate FAQs” combine classical extraction with large language model reasoning over the extracted schema. Custom AI skills can orchestrate multi-step workflows that chain model invocation, metadata updates, list operations, and page changes.
Architectural Shift: From Features to Agents and Skills
Historically, Syntex-based solutions were designed feature by feature: administrators enabled specific Syntex capabilities on individual libraries and then chained the outputs into Power Automate flows or custom applications. Each Syntex meter was closely associated with an explicit configuration step in SharePoint, which made PAYG services cost-controlled and scalable!
AI in SharePoint introduces agents and skills as the primary orchestration layer. Each SharePoint site gains an agent that can execute reusable skills defined within the site.
Skills biggest drawbacks
1. No Version Control or Rollback – Skills are stored as markdown in SharePoint. Edit and save, it’s live immediately. No git history, no rollback, no undo. Break a skill, and you’re restoring from backups (versioning in SharePoint ☺️).
2. Testing in Production – No sandbox or staging environment. You write the skill, submit it, and it runs on real data. No way to test at scale before hitting production. One mistake and you’ve modified thousands of records (and by default, everyone can create a skill ☺️)
3. Not Scalable Across Sites – Skills live in a specific site’s Agent Assets library. If you need to deploy a skill to multiple sites, you do it manually for each one. No centralized distribution, no inheritance, no reuse across the tenant.
Skills biggest advantages
1. Write Once, Run Anywhere – Skills execute across your entire site. One skill handles documents from HR, Finance, and Legal libraries without modification. True reusability—no need to rebuild logic per library.
2. Faster Than Traditional Automation – Compared to Power Automate flows, skills are quicker to write and deploy. Markdown beats visual designers. Less ceremony, faster iteration.
In conclusion, skills describe repeatable AI workflows over the site’s content, such as review, enrich, or route operations, and are implemented as Markdown definitions stored in the Agent Assets library. SharePoint AI provides the underlying services (OCR, translation, extraction, classification), while Copilot licensing covers the interactive experiences.
From an enterprise architecture perspective, existing solutions and models remain a valuable asset. New solutions should be designed around AI in SharePoint and Autofill and skills as the primary user experience layer.
Operationally, organizations should continue to monitor consumption through Azure Cost Management for PAYG meters while tracking AI in SharePoint adoption via Microsoft 365 usage analytics. Governance and compliance continue to leverage SharePoint’s retention, DLP, and permission model, which now also applies to agent and skill definitions themselves. This ensures that AI workflows, training sets, and generated content are subject to the same controls as traditional content.
Long story short:
The Syntex era has ended, but its capabilities live on as part of AI in SharePoint. Meters still bill, models can be reused—but their behavior has changed. Validate before production, treat this as a refresh, not a swap.
Gokan Ozcifci
A huge thank you to Drew Madelung for the detailed feedback and reality checks throughout this article. His insights helped sharpen every section—from catching the oversimplified claims about OCR to pushing me to be honest about autofill’s real-world limitations. Drew brought the enterprise perspective that transforms a product overview into something genuinely useful for architects and teams navigating this transition. His section on “What should you do with your current Syntex setup” is required reading for anyone holding Syntex models hostage.
What should you do with your current Syntex setup
If you’ve already invested in Microsoft Syntex and built models, bound them to libraries, and wired Power Automate flows around them, you’re not behind. You’re actually in a better spot than tenants starting from scratch, because the work you did is still valid and can be converted. But the operating model for that work is changing, and you need to develop a plan for what you can do moving forward. Here’s the order I’d put it in.
1 – Inventory before you celebrate
Pull a list of every Syntex model in your tenant, what it’s bound to, and what depends on its downstream output, flows, custom apps, and third-party integrations. Microsoft’s reuse story is real, but it’s a reuse story for the model. The shift from a human-trained model will not be a 1×1 when moving to an LLM-based classification and extraction.
2 – Treat this as governance work, not platform work
The libraries where you turned Syntex on were, by definition, libraries with high-value structured content. Those are now the libraries Copilot and AI in SharePoint will reason over by default. Re-ask the questions that were used to build those models or use cases in which Syntex was done and decide if there is better AI in SharePoint features to execute those governance actions.
3 – Map by feature
Use this blog post as a tool to figure out what you need to enable and learn with AI in SharePoint to start the transition and subsequent disablement in certain Syntex scenarios. Educate yourself on the current AI in SharePoint tech details to ensure you understand how to configure moving forward.
4 – Pilot skills somewhere boring
Skills are interesting, agent-driven orchestration is genuinely new, and the Agent Assets library deserves a real governance review before you let business-critical workflows live there. Pick a low-stakes site, an internal team that won’t be hurt if something gets edited, deleted, or executed unexpectedly, and learn the there. The interesting skills are the ones that touch content; the interesting failures are the ones that touch the wrong content.
5 – Keep the receipts
Don’t tear down your Microsoft Syntex configuration documentation, your model training notes, or your cost baselines yet. We’re in the middle of a transition, the meters still bill, and “Microsoft moved my cheese” is going to be a recurring conversation with your finance partner for a period of time. The documentation you have now is leverage you’ll want later.
Nothing you built is wasted, but nothing you built is finished either. Treat this as a refresh, not a re-platforming.
Drew Madelung – Microsoft MVP
Hope that helps,
Renewed Revolution
Leave a Reply