Azure Functions para escritórios: aviso de formulário de consulta

Um escritório profissional pode perder confiança com uma automação pequena: o formulário envia herança, trabalhista ou contrato por e-mail, registra todo o texto e não mostra falhas. Este artigo revisa Azure Functions com Claude Code antes do uso real.

Key Points

A revisão começa por dados pessoais, consentimento, texto confidencial, falha de e-mail, duplicados e caminho de agenda. HTTP trigger ajuda, mas anonymous, raw logs e secrets em texto claro são riscos.

Workflow From Form to Booking

O fluxo vai do formulário até reunião ou retorno. Claude Code revisa function.json, app settings, logs, Key Vault references e falhas. O escritório decide quais consultas viram reunião.

Flow	Azure Functions review	Human review
Form receive	HTTP trigger, method, auth, CORS	consent text and accepted case types
Notice	masked subject, request id, mail failure	confidential content and staff owner
Secret	app settings, Key Vault references	mail API key and access policy
Failure	retry record, alert, request id	callback and client communication
Booking	completion page and booking URL	whether the case can be booked

What Claude Code Does and What Humans Decide

Claude Code drafts the Function shape, validation fields, logging policy, Key Vault note, failure checklist, and booking path. Humans decide legal, tax, labor, license, privacy, advertising, confidentiality, and whether to accept the consultation.

3 Use Cases

Use case 1: Split form fields and logs

• Input: form fields, case types, privacy consent, booking URL.
• Output: required fields, optional fields, mail fields, no-log fields.
• Human review: consultation text, personal data, advertising wording, urgent cases.

Use case 2: Review HTTP trigger settings

• Input: function.json, methods, authLevel, App Service auth note, form origin.
• Output: POST-only rule, CORS note, auth warning, and test commands.
• Human review: public exposure, bot protection, stopped services, and phone-first cases.

Use case 3: Handle mail failure and booking path

• Input: mail provider, failure log, retry owner, booking URL, completion page.
• Output: failed notice record, retry rule, staff alert, and booking button rule.
• Human review: which cases can book automatically and which need a call.

Copy-Paste Prompt

Act as a Portuguese professional services Azure Functions consultation-form reviewer.
Goal: prevent missed notices, personal-data logs, plain secrets, and missing booking paths.

Review:
- form fields and case types
- privacy consent
- function.json
- app settings draft
- mail provider note
- completion page and booking URL

Return:
1. HTTP trigger method and auth review
2. raw-body log warning
3. secret and Key Vault reference note
4. failed-notice retry checklist
5. booking path and staff owner
6. five settings a beginner should inspect today

Working Check Code

// verify-azure-function-consultation-form.mjs
// No dependencies. Run with: node verify-azure-function-consultation-form.mjs
const functionJson = {
  bindings: [
    {
      authLevel: "anonymous",
      type: "httpTrigger",
      direction: "in",
      name: "req",
      methods: ["post"]
    },
    {
      type: "http",
      direction: "out",
      name: "res"
    }
  ]
};

const source = [
  "module.exports = async function (context, req) {",
  "  console.log(req.body);",
  "  const apiKey = 'SENDGRID_API_KEY_plain_text';",
  "  await sendMail(req.body.email, req.body.message, apiKey);",
  "  context.res = { status: 200, body: 'ok' };",
  "};"
].join("\n");

const formPolicy = {
  fields: ["name", "email", "caseType", "message"],
  required: ["name", "email", "caseType", "message", "privacyConsent"],
  hasIdempotencyKey: false,
  hasRetryQueue: false,
  hasReservationLink: false
};

const problems = [];
const trigger = functionJson.bindings.find((binding) => binding.type === "httpTrigger");

if (!trigger || trigger.authLevel === "anonymous") {
  problems.push({ item: "authLevel", fix: "avoid anonymous public posting unless another protection layer exists" });
}
if (/console\.log\(req\.body\)/.test(source)) {
  problems.push({ item: "raw body log", fix: "log request id and case type, not the consultation details" });
}
if (/SENDGRID_API_KEY|API_KEY_plain_text/.test(source)) {
  problems.push({ item: "plain secret", fix: "use Key Vault references or approved app settings" });
}
if (!formPolicy.required.includes("privacyConsent")) {
  problems.push({ item: "privacy consent", fix: "require consent before sending the consultation form" });
}
if (!formPolicy.hasIdempotencyKey) {
  problems.push({ item: "duplicate submit", fix: "store an idempotency key from email, timestamp bucket, and message hash" });
}
if (!formPolicy.hasRetryQueue) {
  problems.push({ item: "mail failure", fix: "record failed notices and retry or alert a staff member" });
}
if (!formPolicy.hasReservationLink) {
  problems.push({ item: "booking path", fix: "include a reservation or callback path after the notice" });
}

if (problems.length > 0) {
  console.table(problems);
  process.exitCode = 1;
} else {
  console.log("Azure Functions consultation form checklist passed.");
}

Pitfall: Common Failure Cases

O erro é testar só se um e-mail chegou. O ponto real é cada consulta ficar registrada, protegida e atribuída.

The first failure is calling the project done when email arrives once. A professional office needs traceability for missed notices, duplicate submissions, and booking handoff.

The second failure is logging the whole consultation text. Store request id, case type, time, and result instead.

The third failure is using a plain API key in source code or notes. Move secrets to an approved settings flow and consider Key Vault references.

FAQ

P. O texto da consulta deve ir no e-mail?\n\nR. Depende da política. Se há muitos encaminhamentos, use e-mail mascarado e guarde detalhes em local mais seguro.

Q. Are Azure Functions too much for a small office?

A. Sometimes. If a form service already handles consent, notice, and booking, use it. Functions help when the office needs custom routing, retry records, and integration with booking or internal tools.

Q. Is a Function key enough?

A. It depends on exposure. Public forms may need bot protection, CORS review, rate limits, App Service authentication, or another gateway.

Q. Where should teams go next?

A. Offices that need forms, Azure Functions, Key Vault, logging policy, and booking flow reviewed together can start from ClaudeCodeLab training.

What I Verified

Em português, mantive formulário, privacidade, falha de aviso, agenda e CTA de consultoria. I checked Azure Functions HTTP trigger, triggers and bindings, Key Vault references, App Service authentication, and Azure Functions security. I also checked the CTA, internal link, executable JavaScript, and locale coverage.