Using a protocol email account (public sector) with Make – real-world experiences?

Questions
,
1

:bullseye: What is your goal?

’m evaluating the possibility of automating some workflows related to a protocol email account within a publicly-owned company, using Make (or similar automation tools).

I’m aware that this is a sensitive topic due to:

security requirements
document management regulations
GDPR and audit/logging constraints

For this reason, I’d like to understand if anyone has practical, real-world experience with similar scenarios:

Have you successfully integrated a protocol email account (or official PEC/institutional mailbox) with Make or other cloud automation tools?
If yes, what kind of architecture did you use (direct integration, internal middleware, official APIs from the protocol system, etc.)?
What limitations or constraints were imposed by IT departments, DPOs, or software vendors?
Did you implement any specific safeguards (e.g. data filtering, anonymization, logging, EU-only data processing, etc.)?

The goal is not to push non-compliant solutions, but to understand which approaches have actually been adopted in similar contexts and are considered sustainable.

:thinking: What is the problem & what have you tried?

The goal is to automate part of the workflow related to a protocol email account (incoming messages, attachments, and basic routing/notifications), within a publicly-owned company context.

The challenge is not technical integration itself, but ensuring compliance with:

internal IT security policies
GDPR and data handling requirements
document management and traceability constraints typical of protocol systems

So far, I have explored:

the possibility of connecting the mailbox directly to Make (e.g. via IMAP/SMTP or email modules), but this raises concerns about data leaving the controlled environment
alternative approaches involving an intermediate layer (internal middleware or API-based integration), but without a clear reference architecture yet
internal constraints, which suggest that direct use of external SaaS tools on protocol data may be restricted or require specific safeguards

At this stage, I’m trying to understand what approaches are realistically viable in similar organizations, before moving forward with a concrete implementation.
I’m aware that this is a sensitive topic due to:

security requirements
document management regulations
GDPR and audit/logging constraints

For this reason, I’d like to understand if anyone has practical, real-world experience with similar scenarios:

Have you successfully integrated a protocol email account (or official PEC/institutional mailbox) with Make or other cloud automation tools?
If yes, what kind of architecture did you use (direct integration, internal middleware, official APIs from the protocol system, etc.)?
What limitations or constraints were imposed by IT departments, DPOs, or software vendors?
Did you implement any specific safeguards (e.g. data filtering, anonymization, logging, EU-only data processing, etc.)?

The goal is not to push non-compliant solutions, but to understand which approaches have actually been adopted in similar contexts and are considered sustainable.

3

Hey @Giuseppe_Brau !

Yes, but usually not as a direct mailbox to Make setup.

In this kind of environment, the workable approach is usually an internal middleware layer between the protocol mailbox or protocol system and Make. The middleware handles mailbox access, filtering, logging, and any sensitive processing inside the controlled environment, then only sends the minimum required data to Make for routing or notifications.

Direct integration is usually where IT and compliance push back, especially if full email bodies, attachments, or personal data leave the internal environment. The more acceptable setups usually rely on official APIs, internal relays, or a protocol system export layer instead of exposing the mailbox directly to a cloud automation tool.

Typical constraints are approval from IT security, DPO review, limits on which data can leave the environment, retention and audit requirements, and sometimes a complete ban on external SaaS touching protocol content directly.

The common safeguards are data minimization, stripping attachments unless strictly needed, masking personal data, logging every handoff, and keeping the authoritative document flow inside the internal system.

So yes, similar workflows can be automated, but usually only with a controlled architecture where Make handles downstream orchestration, not the core protocol data processing directly.

Ethan Marcellus- Automation Expert at Tuesday Wizard | Top Make Solution Partner | Make Community Contributor