WEBINAR @ 13th May, 2 PM (GMT+1)
What's Stopping Progress in Higher Education?
Register now
Full Fabric is now listed on Microsoft Marketplace.
For higher education institutions that already run large parts of their estate on Microsoft, this is more than a catalogue entry. Many universities and business schools rely on Microsoft for identity and access management, productivity, collaboration, CRM, cloud infrastructure, analytics, and the procurement and IT governance processes that sit around them. A listing inside that ecosystem makes a purpose-built student lifecycle platform easier to find, easier to evaluate, and easier to fit into an architecture that IT teams already understand.
The strategic point is simple. The Microsoft stack is a strong horizontal enterprise foundation. It is not, on its own, a higher-education-specific operating system for the student journey. Commerce, Admissions & Enrolment, and student information workflows are complex, institution-specific, and expensive to build from scratch. That gap is exactly where a specialised platform earns its place.
Here is the direct answer for the people who will make the decision. Full Fabric's Microsoft Marketplace listing matters because it gives Microsoft-first higher education institutions a clearer way to discover a purpose-built student lifecycle platform that can complement Microsoft Entra ID, Dynamics 365, Microsoft 365 and existing institutional systems, reducing the need to custom-build complex student lifecycle workflows. The listing can support discovery and evaluation, and, depending on offer configuration and institutional procurement rules, may support procurement alignment where applicable. It does not, by itself, guarantee that procurement will be simpler for every institution, and it does not mean Microsoft endorses the product.
This article explains what the listing is, what it says, why it matters for Microsoft-first institutions, and the build-versus-buy questions IT leaders should ask before committing to a bespoke student lifecycle project.
The development and maintenance of an in-house system is a complex and time-consuming task. Full Fabric lets you turn your full attention to maximizing growth and performance.
Microsoft Marketplace is Microsoft's unified destination to find, try, buy and deploy cloud solutions, AI apps and agents from Microsoft and its partner ecosystem. Microsoft relaunched it on 25 September 2025, merging the former Azure Marketplace and Microsoft AppSource into a single storefront so customers no longer have to navigate several separate catalogues. At launch it spanned tens of thousands of cloud and industry solutions across categories including data and analytics, productivity, collaboration, security and industry-specific offerings, and it introduced a dedicated category for AI apps and agents. It launched first in the United States, with a wider rollout following.
For enterprise and public-sector buyers, the practical appeal is that Marketplace sits inside the Microsoft commercial environment they already use. Purchases can be associated with a Microsoft billing account, and eligible Marketplace purchases can count towards an organisation's Microsoft Azure Consumption Commitment where the offer qualifies. Microsoft also supports private offers, which allow a publisher to extend negotiated pricing, custom terms and specialised configurations to a specific customer, with the customer accepting those terms through the Azure portal under their existing agreement. Microsoft documents private offers as supporting customised pricing for a defined period and the bundling of multiple products from the same vendor.
Two distinctions matter for higher education readers. First, being listed is not the same as being endorsed. A Marketplace listing indicates that a solution is discoverable and, where configured, transactable through a Microsoft channel. It does not mean Microsoft recommends the product, and it should not be read as a technical, security or compliance certification unless an official Microsoft source states that explicitly. Second, procurement outcomes depend on configuration. A listing can make a procurement conversation easier to start; whether a specific transaction can flow through an institution's preferred Microsoft route is a question to confirm with the vendor, the institution's Microsoft account team, and its own procurement function.
Full Fabric is listed on Microsoft Marketplace by Spoon Six Limited, the company behind the platform. The listing positions Full Fabric as a "higher education commerce, admissions and student lifecycle platform for Microsoft-first institutions" and describes it, in substance, as a cloud-based platform for managing the student journey from enquiry and application through admissions, enrolment, student records and lifecycle engagement.
That positioning is consistent with how Full Fabric describes itself elsewhere. The platform is presented as modular and composable, and as designed to deploy alongside the Microsoft stack institutions already trust. It brings CRM, Commerce, Admissions & Enrolment, student records and reporting onto one connected record per person, rather than stitching those functions together across separate tools.
You can view the listing directly on Microsoft Marketplace:
https://marketplace.microsoft.com/en-us/product/spoonsixlimited1666812527462.fullfabric
The listing uses the US spelling "enrollment" in places, in line with Microsoft Marketplace conventions. Throughout the rest of this article we use "admissions and enrolment" in UK English, except where an official product name or URL uses the US form.
Most institutions evaluating a platform like this are not starting from a blank sheet. They already have a substantial Microsoft footprint, and that footprint typically does a great deal of work.
Microsoft commonly provides the horizontal foundation of the estate: Microsoft Entra ID for identity and access management; Microsoft 365 for productivity and collaboration; Teams and SharePoint for communication and document collaboration; Dynamics 365 where institutions use it for CRM or wider business applications; Azure for cloud infrastructure; and Power BI for analytics and reporting. These are mature, widely adopted, enterprise-grade tools, and none of the argument that follows depends on treating them as anything less.
The point is a different one. These tools are horizontal by design. They are built to serve any organisation, in any sector, and that generality is their strength. It is also the reason they are not, by themselves, a purpose-built student lifecycle platform. Higher education runs on workflows that are specific to the sector and, often, to the individual institution: enquiry capture and nurture; application forms and applicant portals; document collection; eligibility and prerequisite checks; admissions review and committee decisioning; offers and conditions; enrolment; commerce and payment status where relevant; student records and progression; lifecycle reporting; role-based staff workflows; auditability; GDPR-aligned data governance; and integrations with the LMS, ERP, finance, identity and reporting systems around them.
A Microsoft-first institution should not have to choose between its Microsoft investment and a higher-education-specific platform. The better architecture uses both. Microsoft remains the enterprise foundation, and a specialist platform handles the sector-specific operating layer around the learner. Full Fabric describes exactly this pattern on its page for IT teams: use it as the main platform, or integrate it as a specialist layer for mission-critical workflows, connecting to existing infrastructure rather than replacing it.
When institutions decide to cover the entire student lifecycle by extending Dynamics, building on the Power Platform, or developing custom applications on Azure, they are taking on a build project. Sometimes that is the right call. Frequently, the scale of the commitment is underestimated.
The risks are practical rather than theoretical. Custom builds can create long delivery timelines and unclear ownership. Requirements tend to expand as admissions teams surface edge cases that were not visible at the start: a deferral, a re-application, a conditional offer with an unusual dependency, a sponsored cohort, a programme with its own fee logic. Delivery risk increases when the work depends heavily on an implementation partner, when integrations multiply, and when custom workflows have to be maintained and upgraded over years rather than months. Staff adoption is its own challenge, and so is data governance: a bespoke stack can quietly accumulate duplicated records, uncontrolled exports and drifting access permissions, which is precisely the fragmentation that makes GDPR work harder. Full Fabric's security and GDPR page sets out how fragmentation across tools creates governance difficulty even when each individual system is reasonably secure.
There is also a subtler risk. A general-purpose CRM can be configured to look like an admissions system without actually behaving like one. Teams end up with generic pipeline screens mapped onto a process that does not fit them, rather than purpose-built admissions and student lifecycle workflows.
None of this means custom build is always wrong. Institutions with significant in-house engineering capacity, mature integration platforms and a strong partner can build excellent solutions. The honest question is not whether Microsoft can be extended to do this. It usually can. The question is whether the institution should build and maintain this layer itself, or whether it is about to rebuild functionality that already exists, purpose-built, in a higher education platform. Full Fabric's own complete guide to CRM for higher education frames the same trade-off: architecture, scope and existing systems matter far more than category labels, and neither the build model nor the buy model is automatically better.
It is worth being specific about why these three areas resist a quick build.
For higher education, commerce is rarely just a checkout. It can involve application fees, deposits, short course and executive education payments, microcredential payments, payment status and plans, finance handoff context, employer-sponsored cohorts, and scholarship or discount context where relevant. Full Fabric is not a finance system and does not claim to be. It supports commerce and payment status workflows around the learner journey, connecting application fees, deposits and tuition payments to the applicant and student record, and integrating with payment providers rather than replacing the institution's finance function. Full Fabric's Commerce product covers the product catalogue, applications and payments side of this.
Admissions is where the sector-specific logic is densest: enquiry capture, application forms and portals, document collection, eligibility and prerequisite checks, review and committee workflows, offers and conditions, applicant communications, conversion and yield, and the steps that turn an accepted offer into an enrolled student. These are the workflows Full Fabric's admissions and enrolment software is built around, configured rather than custom-coded so that admissions teams can adjust forms and processes without an IT ticket for every change.
The student information layer carries the record forward: student records, programme enrolment, academic progression, learner history, lifecycle continuity, and alumni status where relevant. The value of a student information system built for higher education is continuity. The record that begins as an enquiry continues through application, enrolment and study without changing system, so registry, finance, admissions, IT and leadership all work from the same person rather than reconciling several copies of them.
These workflows are highly domain-specific, and they have to serve admissions, student services, registry, finance, IT and leadership at the same time. That is a demanding specification for any team to build and then own indefinitely.
The cleanest way to think about this is as two layers that do different jobs.
Entra ID handles identity and access. Microsoft 365 handles productivity. Teams and SharePoint handle collaboration. Dynamics 365 sits in the wider CRM or business-applications landscape where institutions use it. Azure provides cloud infrastructure, and Power BI provides analytics. This layer is general-purpose and serves the whole institution.
On top of that foundation, Full Fabric provides the operating layer around the learner: CRM, Commerce, Admissions & Enrolment, student information, student records, communications, reporting, contextual AI, integrations, role-based workflows, auditability and GDPR-aligned operations. It runs these on a single data model with one record per person, which is what makes lifecycle continuity and governed reporting possible.
This is specialisation, not replacement. Microsoft provides the enterprise foundation. Full Fabric provides the higher education operating layer around the learner. The two are designed to coexist, with a governed integrations approach connecting Full Fabric to the systems around it through pre-built connectors and a documented API.
Microsoft Entra ID, formerly Azure Active Directory, is Microsoft's cloud identity and access management service. It is the system that governs who can sign in to an organisation's Microsoft environment and connected applications, and what they can do once in, through single sign-on, multi-factor authentication, conditional access and lifecycle management. It federates to third-party applications using industry standards such as SAML 2.0, OAuth and OpenID Connect.
This matters for higher education because role-based access has to work across admissions, finance, registry, marketing, student services, leadership and IT, and it has to hold up as people change roles. Full Fabric supports SAML 2.0 single sign-on and SCIM provisioning, and is designed to connect to an institution's existing identity provider. Where that provider is Microsoft Entra ID, staff and student access can be aligned to the institution's central identity, subject to configuration. Full Fabric applies its own role-based access, consent and audit controls on top, so the student lifecycle platform reflects the actual structure of the institution rather than a generic permissions model. Institutions should confirm the specifics of any identity integration with Full Fabric during evaluation.
Dynamics 365 is Microsoft's AI-powered suite of CRM and ERP business applications, used individually or together for sales, service, finance and related operations, and connected natively to Microsoft 365, Azure and the Power Platform. Some institutions use it as an enterprise CRM or business-applications platform.
Full Fabric does not set out to displace Dynamics. Its enterprise connectors extend Salesforce, HubSpot and Microsoft Dynamics 365 with higher-education-specific workflows for applications, evaluations, offers and enrolment, and the institution's CRM can remain the system of record while Full Fabric handles the admissions lifecycle. The connector is CRM-agnostic, so an institution that moves between CRM vendors can reconfigure it without rebuilding its admissions workflows. Dynamics can remain part of the wider CRM or enterprise application landscape. Full Fabric handles the higher education workflows that need deeper sector logic. The Microsoft Dynamics connector is the practical expression of that fit.
Microsoft 365 remains central for productivity, communication and collaboration, and Full Fabric is not a replacement for Teams, Outlook, SharePoint or Office. Its role is complementary: it structures the student lifecycle data and workflows that staff then act on inside their day-to-day Microsoft tools, so that email, documents and collaboration stay where people already work while the learner record stays governed in one place.
Being listed on Microsoft Marketplace means institutions can discover Full Fabric through a Microsoft channel. Depending on configuration, region and institutional procurement rules, that visibility can help with discovery, internal evaluation, vendor visibility, private offer discussions, and alignment with existing Microsoft procurement workflows where applicable.
Microsoft's private offers mechanism is the route through which negotiated commercial terms typically flow on Marketplace. A publisher extends negotiated pricing and terms to a specific customer, and the customer accepts through the Azure portal under their Microsoft Customer Agreement or Enterprise Agreement, which is what allows eligible purchases to align with existing Microsoft commitments. That is a genuine convenience for Microsoft-first buyers, but it is conditional. It depends on the offer being configured for it, on the institution's agreements and billing setup, and on regional availability.
The cautious reading is the correct one. Marketplace availability can make procurement conversations easier to start, and it may support private offers or procurement alignment depending on the institution, the offer configuration and Microsoft Marketplace availability. It does not guarantee that every institution can transact through its preferred route, and it does not promise budget drawdown or automatic procurement. Institutions should confirm the specifics with Full Fabric and with their Microsoft account and procurement teams before assuming a particular path.
Before committing to a bespoke student lifecycle build, it is worth working through a short, honest checklist:
The value of the list is not that it points to a single answer. It is that it separates the workflows worth building from the ones already solved.
For CTOs, CIOs and directors of IT, the listing is useful for a few concrete reasons. It lets a Microsoft-first institution evaluate Full Fabric within a familiar ecosystem rather than as an outlier. It supports a composable architecture instead of a monolithic rebuild, letting the institution keep Microsoft as the enterprise foundation while a specialist platform handles sector-specific workflows. It gives IT a clearer, assessable alternative to custom-building the student lifecycle layer, which can reduce implementation risk relative to a bespoke build where the institutional requirements fit the platform's model. And it supports governance expectations, with role-based access, auditability and GDPR-aligned operations built into the platform, as documented on the Full Fabric Trust Center and its security pages.
The honest caveat is that fit is not universal. The reduction in risk applies when the institution's requirements map reasonably onto the platform. Part of a good evaluation is establishing where they do and do not.
This is not only an IT story. For admissions and student lifecycle teams, the value shows up in daily operation.
A purpose-built platform means applicant and student workflows that reflect how admissions actually works, rather than generic CRM workarounds. It means a stronger applicant experience, clearer communications, and better visibility from enquiry through to enrolment. It means a cleaner handoff from recruitment to admissions to student records, because the record does not change systems along the way. And it means lifecycle continuity, so the person who enquired is recognisably the same person who enrols and, later, becomes an alumna or alumnus. Full Fabric's resources on what universities use CRM systems for describe this joined-up journey in more detail, as does its page for admissions teams.
A simple way to hold the whole picture in mind:
| Layer | Microsoft role | Full Fabric role |
|---|---|---|
| Identity | Entra ID for identity and access management | Aligns access to student lifecycle workflows via SAML 2.0 SSO and SCIM, where configured |
| Productivity | Microsoft 365 for productivity and collaboration | Structures the student lifecycle data and workflows staff act on |
| CRM and business apps | Dynamics 365 where used for CRM or wider applications | Complements with higher-education-specific CRM, admissions and enrolment workflows |
| Cloud and analytics | Azure and Power BI | Provides governed student lifecycle data and integrations |
| Student lifecycle | Horizontal tools require significant customisation | Purpose-built Commerce, Admissions & Enrolment and SIS workflows |
| Governance | Microsoft security and compliance tooling | Role-based access, auditability and GDPR-aligned operations within the student lifecycle platform |
The table is a model, not a contract. The exact division of responsibilities depends on which Microsoft products a given institution runs and how it chooses to configure the fit.
A few recurring errors are worth naming:
Full Fabric's Microsoft Marketplace listing gives Microsoft-first higher education institutions a clearer path to discover and evaluate a purpose-built student lifecycle platform inside an ecosystem they already trust.
The strategic point is not Microsoft versus Full Fabric. It is Microsoft plus Full Fabric. Microsoft provides the strong horizontal enterprise foundation for identity, productivity, collaboration, CRM, cloud and analytics. Full Fabric provides the vertical higher education operating layer around the learner: Commerce, Admissions & Enrolment, SIS and student records, on one connected record. The result, when the fit is right, is less custom build, less delivery risk, a faster route to the workflows that admissions and registry teams depend on, and a better match for the operational realities of higher education.
Institutions can view Full Fabric on Microsoft Marketplace and assess whether it fits their existing Microsoft architecture and student lifecycle strategy:
https://marketplace.microsoft.com/en-us/product/spoonsixlimited1666812527462.fullfabric
Yes. Full Fabric is listed on Microsoft Marketplace by Spoon Six Limited, the company behind the platform. The listing is discoverable within the Microsoft ecosystem and can be viewed at the Marketplace URL above.
It means Microsoft-first institutions can discover and evaluate Full Fabric through a Microsoft channel, and, depending on configuration and procurement rules, may be able to align a purchase with Microsoft procurement workflows. It is primarily a discovery and evaluation benefit, not a change to what the platform does.
No. Full Fabric is an independent, purpose-built higher education student lifecycle platform. It complements Microsoft environments and is designed to work alongside them, but it is not built or owned by Microsoft.
No. Being listed indicates that a solution is discoverable and, where configured, transactable through Microsoft Marketplace. It is not an endorsement, and it is not a technical, security or compliance certification unless an official Microsoft source states that explicitly.
Marketplace availability can support procurement conversations, and Microsoft's private offers mechanism can allow negotiated terms to be accepted through an institution's existing Microsoft agreement where the offer is configured for it. Whether a specific institution can transact through its preferred route depends on region, agreements and configuration. Institutions should confirm the options with Full Fabric and with their Microsoft account and procurement teams.
Full Fabric supports SAML 2.0 single sign-on and SCIM provisioning and is designed to connect to an institution's existing identity provider. Where that provider is Microsoft Entra ID, staff and student access can be aligned to the institution's central identity, subject to configuration. The specifics should be confirmed with Full Fabric during evaluation.
No. Full Fabric complements Dynamics 365 by handling higher-education-specific student lifecycle workflows such as applicant portals, admissions review, enrolment, student records and lifecycle reporting. Its connector lets the institutional CRM remain the system of record while Full Fabric manages the admissions lifecycle.
No. Microsoft 365 remains central for productivity and collaboration. Full Fabric does not replace Teams, Outlook, SharePoint or Office; it structures the student lifecycle data and workflows that staff act on inside those tools.
It can be done, and sometimes it is the right choice. But admissions and SIS workflows are complex, institution-specific and costly to build and maintain. Institutions should assess whether they would be rebuilding functionality that already exists in a purpose-built platform, and weigh the delivery, maintenance and adoption risk against the benefit.
Ideally a group: IT leadership (CTO, CIO, enterprise architects), the data protection officer, procurement, and the admissions, registry and student lifecycle leaders who will live with the workflows. The strongest evaluations include the people accountable for the platform after go-live.
Full Fabric on Microsoft Marketplace
Microsoft Marketplace and procurement
Microsoft ecosystem
Full Fabric
