User Profile
SanjayJanardhan
Frequent Visitor
Joined 1 year ago
User Widgets
Contributions
Re: Office 365 Email activity: SSO-only connection, team testing, and deployment pipelines
tayloramy thanks for the response. Service principal had all the required access ans was able to send emails, but problem is team memeber can not use this connection as it can not be shared with others. Same problem will be caused during the Fabric Deployment Pipeline. So basically it is not production ready activity.79Views0likes0CommentsRe: Office 365 Email activity: SSO-only connection, team testing, and deployment pipelines
Finally I took the direction of creating a logic app which is a sclable solution to resolve this issue, Office 365 mail connection will cause below problems - You can not share the connection to other fellow developers in team, so it will be blocker - As you can not share the connection, person deploying the pipeline using the Fabric Deployment Pipeline should make the code change and take over I know there are workound for above challenges, if you prefer to have a maintainable solution then LogicApp is the way to go.80Views0likes0CommentsRe: Office 365 Email activity: SSO-only connection, team testing, and deployment pipelines
Hi tayloramy Based on the discussion, it appears that Office 365 Mail is not a suitable activity for a mature deployment pipeline setup. I tested using a shared mailbox, and email delivery via delegation works correctly. However, the key challenge remains the Deployment Pipeline, which makes this approach difficult to manage from an ALM perspective. I’m therefore evaluating alternative, more scalable options. In summary, the Office 365 Mail activity works functionally, but falls short when it comes to ALM and deployment pipeline compatibility. v-dineshya Thank you for direction, will explore logic apps to send email notification. Thanks, Sanjay2.5KViews1like1CommentOffice 365 Email activity: SSO-only connection, team testing, and deployment pipelines
Hello, We use the Office 365 Email activity in Microsoft Fabric pipelines. The connection appears to require interactive SSO and cannot be shared with other users the way many other connections can. Problems we see Collaboration / testing: When a teammate needs to test, they must point the activity at their own connection and sign in with their SSO. That drives artifact or parameter churn we would prefer to avoid. Deployment pipelines: Deployments seem to depend on who performs the deploy and whether they own (or can use) the Office 365 Email connection. If the person running the release is not the connection owner, we hit authorization / resolution issues. Approach we are considering Use a dedicated service principal (automation account) as the identity that owns the Office 365 Email connection in the workspace(s). Grant that service principal the workspace / artifact permissions needed to author and run pipelines. Run deployment pipeline releases (or automation that deploys) as that same service principal so the connection owner and deploy identity stay aligned. Questions for the community and product team Is the above supported and recommended for Office 365 Email in Fabric, or are there known limitations (e.g. connection still bound to a user, Graph/mail permissions, Conditional Access)? For ALM, what is the recommended pattern today: shared automation identity, per-environment connections, parameters only (no connection switching per developer), or something else? Are there roadmap items or ideas we should follow for shareable Office 365 Email connections or clearer deployment-pipeline behavior for this activity? Pointers to documentation or similar solved threads are appreciated. Thank you.Solved2.8KViews0likes11Comments
Data Privacy
Microsoft Fabric Community and Privacy
To learn more about how we manage your data, please review the Microsoft Fabric Community Data Privacy guide.