#Salesforce Admin314 debatiendo

Hola Juan, 

El examen en sí (preguntas del examen) sí está disponible en español (LATAM), así que podés rendirlo directamente en ese idioma sin problema, la traducción del examen la hace Salesforce oficialmente. 

Para preparación, el trailmix oficial de Salesforce es este, y también tiene versión en español (LATAM): 

Un detalle importante: aunque el trailmix esté en español, los desafíos prácticos (hands-on challenges) por ahora solo están traducidos en un grupo limitado de módulos prioritarios (japonés, español LATAM y portugués BR), el resto sigue solo en inglés. Si al hacer un challenge en español te falla la validación, probá cambiando el idioma/región de tu Trailhead Playground a inglés (US) y repetilo con las instrucciones en inglés, a veces la traducción del challenge queda desactualizada respecto al inglés original. 

Sobre la complejidad, la Guía Oficial del Examen (Exam Guide) en Trailhead es el recurso más confiable para saber exactamente qué porcentaje de preguntas corresponde a cada tema (seguridad, automatización, datos, etc.), vale la pena revisarla antes de armar tu plan de estudio. 

Referencia:

Hey Renuka, 

A record page's actions are a combination of Quick Actions, standard buttons (Edit, Delete, Clone), Chatter actions, and productivity actions, all rendered together in the page-level action menu, but they trace back to different generations of the platform. 

Standard buttons like Edit predate Quick Actions entirely, they're core CRUD operations baked into Salesforce since Classic, tied directly to page layouts and standard controllers. Quick Actions came later (Lightning-era) as a more flexible, declarative framework built for things standard buttons couldn't do well: creating related records, logging calls, launching Flows/LWCs, all without needing a full page navigation. 

Salesforce never migrated Edit/Delete/Clone into the Quick Action framework because they're fundamental object-level behaviors tied to page layout metadata and permissions, not something layered on top. Rebuilding them as Quick Actions would be redundant and risk breaking backward compatibility across every existing org. 

So the short answer: it's not that they overlap by design, it's that Standard Buttons are older, layout-level plumbing, and Quick Actions are a newer, more flexible layer built alongside them, not a replacement for them. 

Reference:

Thanks for testing those, Souvik - since browser, My Domain, and admin are all ruled out, that error is almost certainly coming from one specific org-wide setting: 'Require Proof Key for Code Exchange (PKCE) Extension for Supported Authorization Flows' in Setup > OAuth and OpenID Connect Settings. 

Here's the trap: you mentioned enabling PKCE there. When that org-wide toggle is on, the org forces a code_challenge on every supported authorization flow - but the internal namespace-linking flow doesn't send one, so it fails with exactly 'missing required code_challenge'. So that setting being enabled is what's breaking the link, not something you're missing. 

The fix: turn that setting off (Setup > OAuth and OpenID Connect Settings) in the org that owns the namespace - and in the Dev Hub too if it's enabled there - then retry the namespace link. Once it's linked, you can switch it back on if you want PKCE enforced for your own apps. Note this org-wide toggle is separate from the greyed-out PKCE box on the Salesforce-managed connected app you can't edit - this one you do control. 

If it's already off and still fails, then it's on Salesforce's side (the managed linking app), and the right path is a Partner Support case referencing the error - it's a managed flow you can't patch yourself. But I'd bet on the org-wide setting; toggle it off and the link should go through. 

Hope that finally clears it! 

And if this resolves it, please mark it as the Best Answer so it helps the next person who hits this - thanks! 🙂

Hi Tracy - yes, Apex Messaging.sendEmail with SingleEmailMessage.setToAddresses() is the right native fit for RAW emails (no records needed, and with no names a static body needs no merge). Two refinements: 

1. Don't run it from Dev Console Execute Anonymous - that's a single synchronous shot with no restartability and it can hit governor limits. Use Batch Apex (or Queueable) and chunk it: up to 100 addresses per SingleEmailMessage, so ~50 emails total. 

2. Mind the cap - it's 5,000 EXTERNAL addresses/day per org for Apex single email (the error is SINGLE EMAIL LIMIT EXCEEDED). 5,000 fits in one day but leaves zero headroom, so if anything else in the org sends email that day you'll blow it. Safer to split across two days or run it first thing. 

The bigger flag though: Salesforce's transactional email isn't a bulk-marketing engine. 5,000 near-cold sends from raw addresses can dent your org's deliverability/reputation, and you get NO unsubscribe link, bounce handling, or open tracking. If this is marketing/newsletter, a real platform (Account Engagement/Pardot, Marketing Cloud, or even Mailchimp) is the right call - better inbox placement + built-in CAN-SPAM unsubscribe. 

If you'd rather stay native and no-code: import the 5,000 as Leads, build a list view, and use Lightning 'List Email' with your template - same 5,000/day cap, but zero Apex. 

If this helps, please mark it as the Best Answer so it helps the next person 🙂