Forum Discussion
Architecture question - Email send functionality - Pattern
Dear all,
As a Fabric Architect, I've been asked to add our approach for sending email notifications from Fabric into our TDA. This is something I'm comfortable designing, but I'd really appreciate the community's input.
Our architecture is organised into Raw, Bronze, Silver, and Gold layers. The first three are owned by the data engineering team. Gold, following the data mesh approach, is owned by the domain teams.
In terms of workspaces: Raw, Bronze, and Silver each have a single dedicated workspace, while Gold has one workspace per domain. We also have three environments — Dev, Test, and Prod — each with the same number of workspaces and layers.
All email traffic here is internal only — every recipient is inside our own tenant, nothing client-facing.
I want to design a strategy for sending emails from pipelines, notebooks, and other Fabric items. From what I've read, there seem to be a few options:
- The Outlook activity inside pipelines
- The Graph API from notebooks
- Logic Apps or Azure Communication Services (ACS) Email for client-facing scenarios
Given everything stays internal, option 3 feels like the wrong tool from the start — its whole value is branding and deliverability outside the tenant, which isn't a factor here. The Outlook activity is also still in public preview. And more generally, I don't think a TDA should document several different approaches for the same capability — it should land on one clear, defensible pattern.
My current thinking is to create a dedicated shared-services workspace — named specifically for the capability (e.g. "Shared Services: Notifications" rather than a generic catch-all), since other shared capabilities beyond email will likely need the same treatment eventually. I'd put the send-mail logic there once, and call it from wherever a notification needs to be sent — pipelines, notebooks, Data Activator, and so on.
The method I'm settling on for what's actually inside that notebook is the Graph API, app-only (client credentials), roughly:
python
The app registration is scoped to a single mailbox via Exchange Online RBAC for Applications, so this credential can't send as anyone else in the tenant.
How are you all approaching email from Fabric? I'd love to hear how others are architecting this, whether the shared-services pattern holds up in your experience, how you're naming/structuring these cross-cutting capability workspaces, and whether Graph API app-only is what you've landed on too.
Thanks in advance,
Pedro
4 Replies
Hello fabricpribeiro,
I agree with the shared services pattern. Email is a cross-cutting capability, so keeping it separate from the Raw, Bronze, Silver, and Gold ownership model makes sense.
For an internal-only scenario, Microsoft Graph with app-only permissions is also a reasonable fit. Graph documents Mail.Send as the least-privileged application permission for sendMail, while Exchange Online RBAC for Applications allows that application access to be scoped to specific mailboxes.
https://learn.microsoft.com/en-us/graph/api/user-sendmail
https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac
I also like the idea of centralising the email logic rather than having each workload implement its own approach. Microsoft now documents a reusable email-pipeline pattern for the Office 365 Outlook activity, which is quite close to that principle.
https://learn.microsoft.com/en-us/fabric/data-factory/outlook-activity
Shared Services - Notifications is also a clear naming choice for a cross-cutting capability.
Hi fabricpribeiro,
The graph approach is the one I would choose, though I have seen quite a few posts on here of users not able to get it working. I have yet to attempt to send emails through graph myself.
Provided you get the API permissions all sorted out, I would recommend wrapping this in a UDF instead of in a notebook, or perhaps multiple UDFs depending on what types of emails you will be sending.
That way you have a single call to send an email, wither it's called from a pipeline or a notebook or some other item type down the road, it all calls the UDF.
You can also set up the UDF to have standard templates and standardize the email subject and descriptive information about the type of email. For example, you could have a warning UDF that includes details like "this should be investigated, but this did not prevent ETL from moving on" and you can have an error UDF that screams a little louder with something like "drop everything data is no longer flowing to the business"
Dears,
Thanks a lot for your replies
What I read is that I should not use the outlook activities right? instead, I should use this approach graph API, correct?
Thanks a lot, pedro
Hi fabricpribeiro ,
sorry for the delay in response.
Yes, that's correct!! if you have any further questions, please let us know we are happy to address.
Thanks!!
