On a recent project for a community organisation, the website needed to publish events from Outlook calendars, route enquiries from Microsoft Forms, add newsletter sign-ups to Mailchimp, and publish every newsletter on the website the moment the campaign is sent, and let visitors book a free time straight from the team's calendar - without anyone on the team re-entering data. None of that is exotic. But each connection can be built three different ways, and the right choice depends less on the technology than on who will look after it in two years.
What an integration actually is
An integration is any point where your website hands information to another system, or pulls information from one, without a person in the middle. A sign-up form that adds someone to your mailing list is an integration. So is an events page that updates itself when you add an event to a calendar.
The question is never "can these connect?" - with Microsoft 365 and Mailchimp, they almost always can. The questions are how, who owns the connection, and what happens when it fails.
Three ways to connect
Every integration falls into one of three approaches. They trade off cost against control.
Embed - the tool's own widget
Mailchimp, Microsoft Forms and most booking tools give you a snippet to paste into a page. It works the same day and the vendor maintains it. The cost is that it looks like their product rather than yours, it can slow the page down, and you have little control over what happens after someone submits.
Automate - a connector in the middle
Tools like Power Automate (included with many Microsoft 365 plans) or Zapier watch for an event in one system and act in another: a form response arrives, so a row is added to a SharePoint list and the right person is emailed. No code, and staff can often adjust it themselves. The risk is that these flows are invisible until they stop working.
Build - direct to the API
Your website talks to the service's API itself. This is the most seamless result - forms that match your design, content that appears instantly, logic tailored to your process - and the most robust when it is done properly. It needs a developer to set up, and a small amount of server-side code so that private keys never sit in the browser.
The three tools, specifically
Mailchimp
The most common request is a newsletter sign-up that looks like part of your site rather than a Mailchimp box. That means sending the form to Mailchimp's Marketing API from a server or serverless function - never with the API key in the page's JavaScript, where anyone can read it and gain access to your whole account.
- Use tags or groups so you know whether someone signed up from the footer, an event page or a specific campaign.
- Collect clear consent. Australia's Spam Act requires it for marketing email, and a pre-ticked box doesn't count.
- Decide on double opt-in - it lowers sign-up numbers slightly, but keeps your list clean and your deliverability high.
The connection can run the other way too. On that same project, every campaign the team sends in Mailchimp now appears on the website as a newsletter archive, automatically. The site pulls each sent campaign through the API, so past issues become pages people can find, share and search - and the team never publishes the same content twice.
Microsoft Forms
Forms is excellent for internal surveys and registrations, and many organisations already know how to use it. It has no general public API for reading responses, so the supported route is Power Automate: when a response is submitted, pass it to Outlook, Teams, an Excel sheet or a SharePoint list.
For a public-facing enquiry form, it is usually better to build the form on the website itself and then send the result into Microsoft 365. Visitors get a form that matches your brand; staff still receive everything in the tools they already use.
SharePoint
SharePoint is where many teams already keep their documents, policies and event lists. Through the Microsoft Graph API, a website can read from a SharePoint list - so staff update an event or a resource in one familiar place and the website reflects it.
- Read from one dedicated list, never from the wider site. The website's access should be limited to exactly what it publishes.
- Cache the results so the website stays fast and keeps working if Microsoft has a brief outage.
- Keep confidential material elsewhere. A list the public website reads from should be treated as public.
SharePoint also works well as a simple go-between. For one booking system we built, Power Automate reads the team's calendar and writes it into SharePoint as a JSON file - a plain, structured list of which times are taken. The website reads that file and shows it as a calendar: visitors see which slots are booked, pick one that is free, and book it.
The benefit is that the website never touches the calendar itself. It only sees whether a time is busy, not the meeting titles or attendees behind it, so nothing private leaves Microsoft 365.
What quietly breaks
Integrations rarely fail loudly. They stop, and nobody notices until a supporter asks why they never got the newsletter. In our experience, the causes are almost always the same:
- A person's account owned the connection, and that person left. Integrations should run on a dedicated service account, not on someone's personal login.
- A password or token expired. Microsoft app credentials have expiry dates; put the renewal date in a calendar the day you create them.
- Something was renamed. Change a SharePoint column or a Mailchimp field, and the integration that relied on it can fail without warning.
- A licence changed. Some Power Automate connectors need a premium licence, and plans change.
The fix is unglamorous: failure alerts that go to a shared inbox, and documentation that records what connects to what, which account owns it, and when credentials expire. This is part of the handover documentation on every Naseej project.
Questions to ask before you integrate
- What manual task does this replace, and how many hours a month is it really?
- Who will notice if it stops working - and how?
- Whose account does the connection run on?
- What personal information passes through it, and where is it stored?
- If we change tools next year, how hard is it to unpick?
If the honest answer to the first question is "ten minutes a month", an integration probably isn't worth the maintenance. If it is "half a day every week", it almost certainly is.