Custom Formatter for Read-Only Fields conditional based on other columns
Hello! Does anyone know if it's possible with the fieldsettings, readonly formatting, to make it conditional based on a Person field? It's a multi people field if that makes a difference? I ideally want to make certain fields read only based on who is viewing it (without having to use a Power App customised form!). This is what I want (but I know the syntax is likely all wrong!) but not sure if it's possible to use an IF statement with boolean statements? { "sections": [ {} ], "fieldsettings": [ { "name": "Comments", "readonly": "=if([$People.email] == me, false, true)" } ] }
Access 2608 Build 20326: Line controls disappear in Print Preview
I believe there may be a regression in Microsoft Access Build 16.0.20326.20034 (64-bit) affecting Line controls in reports. I can reproduce the problem even with a completely new blank MDB database, so it does not appear to be related to an existing application. Steps to reproduce: 1.Start Microsoft Access 64-bit Build 16.0.20326.20034. 2.Create a new blank MDB database. 3.Create a new report in Design View. 4.Add a Line control to the Detail section. 5.Add a Rectangle control to the same section. 6.No VBA code or special event handling is required. 7.Select Microsoft Print to PDF as the printer. 8.Open Print Preview. Actual result: The Rectangle control is displayed correctly, but the Line control disappears in Print Preview. The problem is not specific to a particular printer. We have reproduced it with multiple printers. Expected result: Both the Line and Rectangle controls should appear in Print Preview and in the printed output. Workaround: Rolling Microsoft Access back to an earlier build immediately resolves the problem. The same MDB file and the same report then display and print the Line control correctly. We have also reproduced the issue with Build 16.0.20326.20044 (64-bit). Has anyone else been able to reproduce this with Version 2608 / Build 20326?Distributing Agents to Microsoft Teams and Microsoft 365 Copilot Part 4/5
This is the fourth post in our series on the Microsoft agent platform. We cover the Distribute in M365 pillar — publishing your agents to Microsoft Teams and Microsoft 365 Copilot so they reach users where they already work. All examples reference the FibreOps repository, demonstrated at Microsoft Build BRK241. The Distribution Story Building a great agent is only half the challenge. The other half is getting it into the hands of users without asking them to learn a new tool, visit a new URL, or change their workflow. Microsoft 365 Copilot and Microsoft Teams are where enterprise users already spend their day, making them the natural distribution surface for agents. With the GA release, publishing an agent to Teams and M365 Copilot is a single command. No separate app registration portal, no manual manifest assembly, no multi-step approval workflow for development and testing. Publishing to Microsoft 365 Copilot (GA) FibreOps ships as a declarative agent + action plugin ready for sideload. A single CLI command produces the complete package: python -m fibreops.demo publish-m365 --out dist/m365 # Output: # ✓ wrote dist/m365/declarativeAgent.json # ✓ wrote dist/m365/fibreops-action.json # ✓ wrote dist/m365/manifest.json # ✓ wrote dist/m365/color.png (192x192) # ✓ wrote dist/m365/outline.png ( 32x32) # ✓ wrote dist/m365/fibreops-copilot.zip What Gets Generated File Purpose declarativeAgent.json Defines the agent's persona, capabilities, and conversation starters for M365 Copilot fibreops-action.json Action plugin that proxies tool calls to the deployed FastAPI backend via OpenAPI manifest.json Teams app manifest with publisher metadata, permissions, and capabilities color.png / outline.png App icons for Teams and M365 surfaces fibreops-copilot.zip Ready-to-upload package for Teams Admin Center Configuration Set the base URL to your deployed FastAPI app before publishing — the action plugin uses this to resolve the OpenAPI runtime: # Set the public HTTPS hostname of the deployed FastAPI app $env:M365_ACTION_BASE_URL = "https://fibreops-demo.azurewebsites.net" # Optional: customise publisher metadata $env:M365_PUBLISHER_NAME = "Contoso Network Operations" $env:M365_PUBLISHER_WEBSITE = "https://contoso.com/noc" # Generate the package python -m fibreops.demo publish-m365 --out dist/m365 Environment Variable Purpose M365_ACTION_BASE_URL Public HTTPS root for the FastAPI /openapi.json (e.g., Container Apps FQDN) M365_APP_ID Override the generated Teams app GUID (default: deterministic per repo) M365_PUBLISHER_NAME Publisher name shown in M365 Admin Center M365_PUBLISHER_WEBSITE Publisher website link Uploading the Package Upload the generated fibreops-copilot.zip through either path: Teams Admin Center → Manage apps → Upload new app M365 Admin Center → Integrated apps → Upload custom apps Once uploaded, the declarative agent: Inherits the publisher metadata you configured Advertises conversation starters from the FibreOps deck (e.g., "What is the current outage status?", "Dispatch an engineer to FN-LDN-001") Proxies tool calls to the deployed FastAPI app via the action plugin Appears in Microsoft 365 Copilot as a specialised agent users can invoke How Declarative Agents Work A declarative agent in Microsoft 365 Copilot is defined by metadata rather than code running in the M365 surface. The intelligence lives in your backend — Copilot handles the conversational UX, tool orchestration schema, and user authentication. The flow: User invokes the agent in Microsoft 365 Copilot or Teams Copilot renders conversation starters and accepts natural language input When the agent needs to act, Copilot calls the action plugin (your OpenAPI endpoint) Your FastAPI backend processes the request using the full agent pipeline Results return to the user in the Copilot/Teams UX This architecture means your agent logic stays in one place — the backend. The M365 surface is purely a distribution and interaction layer. Action Plugins and OpenAPI The action plugin ( fibreops-action.json ) references your FastAPI app's /openapi.json endpoint. FibreOps exposes a JSON API that the action plugin can call: /api/runs — List and query agent runs /api/optimiser — Get optimizer scores and suggestions /sdk/chat — Natural language interaction with the agent system /healthz — Liveness probe Because FastAPI auto-generates OpenAPI schemas from your typed Python endpoints, the action plugin gets accurate parameter descriptions, response schemas, and error codes without any manual specification work. Publishing as Autopilots (Public Preview) Autopilots take distribution one step further — agents that operate autonomously without requiring a user to initiate each interaction. An Autopilot can: React to events (e.g., a critical telemetry signal) without human initiation Take actions within defined guardrails Notify users only when human intervention is needed Operate continuously across Microsoft 365 surfaces For FibreOps, an Autopilot would monitor the Event Hub stream continuously and only surface to the NOC team when an incident exceeds automated resolution capability — a fully autonomous operations agent. Teams Adaptive Cards FibreOps posts rich Adaptive Card notifications to Microsoft Teams throughout the agent pipeline. This is separate from the declarative agent — it is a push notification channel for real-time operational awareness. # The NetOps agent posts an outage notice via Incoming Webhook def post_outage_notice(incident_id, node_id, severity, summary, engineer=None): card = { "type": "AdaptiveCard", "body": [ {"type": "TextBlock", "text": f"🚨 Outage: {node_id}", "weight": "Bolder", "size": "Large"}, {"type": "FactSet", "facts": [ {"title": "Severity", "value": severity.upper()}, {"title": "Incident", "value": incident_id}, {"title": "Summary", "value": summary}, ]}, ], "actions": [ {"type": "Action.OpenUrl", "title": "View in NOC Console", "url": f"{base_url}/runs/{incident_id}"} ] } # POST to Teams webhook or append to outbox for offline mode ... If TEAMS_WEBHOOK_URL is not configured, cards are appended to state/teams_outbox.jsonl for review in the NOC console's Teams panel. End-to-End: From Code to Copilot Here is the complete flow from development to distribution: Build — Develop agents with Microsoft Agent Framework, test locally with python -m fibreops.demo --backend local Publish agents — python -m fibreops.demo publish creates hosted Prompt Agents in Foundry Deploy infrastructure — azd up provisions App Service, ACR, Event Hub, Key Vault, and Application Insights Deploy hosted agent — azd env set FIBREOPS_DEPLOY_HOSTED true && azd up Generate M365 package — python -m fibreops.demo publish-m365 --out dist/m365 Upload to Teams — Upload fibreops-copilot.zip via Teams Admin Center Users interact — The agent is now available in Microsoft 365 Copilot and Teams Security Considerations Managed Identity — The deployed app uses system-assigned managed identity for all Azure service access. No secrets in code. Least privilege — Each role grant is scoped to the minimum required (Event Hubs Data Owner, Key Vault Secrets User, AcrPull, Azure AI Developer). Authentication — The M365 Copilot surface handles user authentication; your backend receives authenticated requests. Guardrails — Autopilots operate within defined boundaries; human-in-the-loop escalation is built into the Routine and agent decision logic. Key Takeaways Publishing to Teams and M365 Copilot is GA — a single command generates the complete package. Declarative agents separate distribution (M365) from intelligence (your backend). Action plugins leverage your existing FastAPI OpenAPI schema — no manual specification needed. Autopilots (Public Preview) enable fully autonomous operation within guardrails. Adaptive Cards provide real-time push notifications alongside the conversational agent surface. The same backend serves the NOC console, the Copilot SDK, and the M365 declarative agent. Next Steps Explore the FibreOps repository — try python -m fibreops.demo publish-m365 Microsoft 365 Copilot extensibility documentation Next in this series: Voice Live and Observability for Production Agent Systems
Workflows - Posting a Card
I'm in the process of migrating our Jira integration with teams from using the soon to be deprecated Connectors, to Workflows. I have two problems that I can't see to overcome. 1. All the messages are posted as '[My Name] via Workflows posted a new message'. Is there any way the message can come from another user or no user? 2. The preview for the messages (in the notification popup and Activity screen) is 'Card', instead of anything useful. Together this makes the notifications not very useful. What I have done: The workflow is set up And what is being posted to the webhook is (for example). { "type": "message", "attachments": [{ "contentType": "application/vnd.microsoft.card.adaptive", "contentUrl": null, "content": { "type": "AdaptiveCard", "$schema": "http://adaptivecards.io/schemas/adaptive-card.json", "version": "1.4", "body": [{ "type": "ColumnSet", "columns": [{ "type": "Column", "width": "auto", "items": [{ "type": "Image", "url": "https://i.imgur.com/FrVumxY.png", "size": "Medium" } ] }, { "type": "Column", "width": "stretch", "verticalContentAlignment": "Center", "items": [{ "type": "TextBlock", "size": "Medium", "weight": "Bolder", "text": "Component Missing [ADP-xxx]" } ] } ] }, { "type": "TextBlock", "text": "Initiator: ", "wrap": true }, { "type": "TextBlock", "text": "ADP-xxx: Fixing reset password validation", "wrap": true, "weight": "Bolder", "color": "Accent", }, { "type": "TextBlock", "text": "Status: QA Ready", "wrap": true }, { "type": "TextBlock", "text": "Type: Bug", "wrap": true }, { "type": "TextBlock", "text": "Assignee: ", "wrap": true } ], "actions": [{ "type": "Action.OpenUrl", "title": "Open in Jira", "url": "https://xxx.atlassian.net/browse/ADP-xxx" } ], "$schema": "http://adaptivecards.io/schemas/adaptive-card.json", "version": "1.4" } } ] } I have tried posting various different combinations of summary attributes with no effect. Is there a whole better way of doing this, or is there a few tweaks I can make?
Sharepoint Site News Links not populating like before
Hello, everyone! Has anyone else had an issues within SharePoint and posting news links? Previously, on our SharePoint site we would add news links from sources and the article title, image, and description would autopopulate and then allow users to go click the link to that article. However, since November, SharePoint does not do this anymore and is not pulling in the information. Any assistance would be appreciated.
Ribboncreator2021
RibbonCreator 2021 is one of the most popular tools for creating custom Microsoft Access ribbons without having to write all the Ribbon XML manually. It provides a WYSIWYG (What You See Is What You Get) editor that allows developers to create tabs, groups, buttons, menus, and icons visually, and then export the generated Ribbon XML directly into an Access database. Advantages of RibbonCreator 2021 Easy-to-use visual interface. Automatically generates Ribbon XML. Integrates VBA callbacks for Access applications. Supports custom images and built-in Office icons (idMso). Compatible with Microsoft Access 2021 and Microsoft 365. Alternative Solution Another excellent option is AccessUI Ribbon & Tree Builder, a free Access add-in that enables developers to build complex ribbons without XML knowledge. It also helps generate the required VBA callback procedures automatically. Recommendation For professional Microsoft Access development: RibbonCreator 2021 → Best for advanced customization and full control over the Ribbon interface. AccessUI Ribbon & Tree Builder → Best for rapid development and ease of use. If you are developing Access applications for end users and need a robust, mature solution, RibbonCreator 2021 is generally the better choice due to its comprehensive feature set and direct Access integration. https://ribboncreator2021.de/Microsoft Marketplace Partner Digest
What's new in Marketplace Convert more buyers into customers Microsoft recently expanded Marketplace listing capabilities with enhancements to free trials and the introduction of an option to request private offers, giving partners more ways to engage buyers at different stages of the purchasing journey. Customers can now discover and evaluate solutions through expanded trial experiences and transition more easily into paid subscription discussions by requesting custom pricing and terms directly from your Marketplace listings. ✨ Help customers evaluate your solution with free trials What's new On July 23 we announced the release of Marketplace enhanced trial capabilities. Customers can try solutions with confidence with the free trials in Microsoft Marketplace. Trials are available for multiple offer types, including SaaS, Azure virtual machines, Dynamics 365, and Power BI offers. New capabilities include: Custom meter trials: Partners can configure trials for SaaS solutions with metered pricing. Flexible trial durations: Partners can now configure SaaS trial durations from 1 to 180 days. Partner analytics: Partners can access SaaS trial analytics - including free trials initiated, active free trials, free trials converted, free trials not converted, and average trial duration - all within Partner Center Insights workspace. Customer discovery and management: Customers can better discover and manage trials. Upgrade to paid subscription during trial: Customers can upgrade to paid subscription at public pricing any time during a SaaS trial. Why it matters With enhanced trial capabilities in Microsoft Marketplace, partners can run self-service trials that make it easier for customers to try before they buy — whether for metered, per-user, or flat-rate pricing offers. Marketplace gives partners one place to manage trials end to end — from provisioning and mid-trial changes to insights — while improving offer discoverability through improved search, filters, and dedicated trial badges. Recommended action Review your Marketplace offers and trial strategy. For eligible SaaS offers, evaluate whether free trials can help you engage with more qualified buyers, faster. 📖 Learn more about free trials for SaaS ⚡ Customers can now request a private offer on Marketplace What’s new As of July 20, you can add a private offer request option directly on your Marketplace product pages. Customer requests are captured as Marketplace leads in referrals workspace and connected customer relationship management (CRM) integrations you’ve setup. This setting is disabled by default. You can easily activate it for applicable public offers. Why it matters More and more customers are seeking customized contracts and subscription pricing and terms tailored to their individual needs. This simple call to action reduces friction and helps you start the conversation with prospective buyers. Recommended action In the Marketplace offers workspace of Partner Center, update each of your offers for which you provide customers private offers. Enable the Request Private Offer setting and republish the offer. Events Recent events Multiparty private offers expand channel growth opportunities in Australia, Japan and South Africa Multiparty private offers continue to help software companies accelerate channel-led sales through Microsoft Marketplace. This past month, we hosted two region-focused Marketplace office hours sessions designed to help partners better understand local market opportunities, engage distributors and resellers, and scale Marketplace transactions through channel ecosystems in Australia and Japan. Whether you're looking to expand an existing Marketplace motion or explore new geographic opportunities, these sessions will provide practical guidance and market-specific insights to help you grow. See a list of currently supported countries/regions. Check out the recorded sessions: • Channel growth in Australia (English) • Channel growth in Japan (Japanese) Helping developers build, monetize, and scale AI solutions with Marketplace Discover how Microsoft Marketplace helps software companies access AI models and developer tools, accelerate application development, and reach customers through Microsoft's global commercial ecosystem. Learn how to monetize applications and agents without building and maintaining your own commerce and distribution infrastructure. Watch the recording Upcoming events Build AI-powered solutions, monetize through Microsoft Marketplace, and scale revenue through Microsoft expertise, skilling, and investments. Frontier Accelerate for Marketplace is an upcoming unified offering for software development companies to bring AI-powered solutions to market, drive customer acquisition and revenue growth, and scale through Microsoft Marketplace with technical guidance, skilling, and investments aligned to every stage of growth. 📆 Join us on August 26th before general availability to learn about the new offering, benefit alignment, migration guidance, and enrollment requirements. Next steps Turn insights into FY27 success — starting today. Ready to carry the momentum forward from MCAPS Start for Partners? Get everything you need to refine and execute your FY27 strategy in the Partner Activation Zone, including session recordings, ready-to-use playbooks, and tools to start building pipeline. Leverage your Marketplace Rewards benefits Discover use cases and how to leverage your Azure sponsorship. With Marketplace Rewards Azure sponsorships, eligible software development companies can increase sales through Microsoft Marketplace by using the sponsorships for customer deployments tied to Marketplace deals—and to offset infrastructure costs from eligible free trial offers. 📍Review the Marketplace Rewards Azure sponsorship policy guide for the latest
App Validation failing for no clear reason
We're trying to get our (very simple) Teams App listed on the app store, but during the App Validation we keep getting the same error: "Unable to upload the manifest.zip file in MS Teams." as seen below: Downloading the report doesn't give any more information, it only lists the only successful validation step ("BotID should be registered") and the error doesn't appear there. I've validated the manifest.json file against the schema, tried reuploading the same manifest to a different org (creating a new app and bot) - validation fails there too. Does anyone have any pointers? Here is my (anonymized) manifest file: { "$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.19/MicrosoftTeams.schema.json", "manifestVersion": "1.19", "version": "1.1.1", "id": "[redacted]", "developer": { "name": "[redacted]", "websiteUrl": "https://www.[redacted].com", "privacyUrl": "[redacted]", "termsOfUseUrl": "[redacted]" }, "icons": { "color": "color.png", "outline": "outline.png" }, "name": { "short": "[redacted]", "full": "[redacted]" }, "description": { "short": "[redacted]", "full": "[redacted]" }, "accentColor": "#4A3AFF", "bots": [ { "botId": "[redacted]", "scopes": ["personal"], "supportsFiles": false, "isNotificationOnly": false, "commandLists": [ { "scopes": ["personal"], "commands": [ { "title": "help", "description": "Show what this bot does and how to connect your account" }, { "title": "connect", "description": "Get a fresh link to (re-)connect your account" } ] } ] } ], "staticTabs": [ { "entityId": "conversations", "scopes": ["personal"] }, { "entityId": "about", "scopes": ["personal"] } ], "permissions": ["identity", "messageTeamMembers"], "validDomains": ["app.[redacted].com", "auth.[redacted].com"] }
