Salesforce Developer Salesforce Developer

Salesforce에서 자동화를 구현하는 방법은 여러 가지가 있지만, 최근 수년간 Flow가 사실상 표준 자동화 도구로 자리를 잡았습니다. Process Builder와 Workflow Rule이 단계적으로 은퇴 수순을 밟고 있고, Salesforce도 Flow를 중심으로 자동화 기능을 강화하고 있습니다. 그런데 Flow는 클릭 몇 번으로 만들 수 있는 만큼, 잘못 설계했을 때 생기는 문제도 눈에 잘 띄지 않습니다. 운영 중에 갑자기 오류가 터지거나, 퍼포먼스가 저하되거나, 기대하지 않은 시점에 트리거되는 일이 생깁니다. 이번 글에서는 Flow를 설계할 때 실무에서 정리한 Best Practices를 소개합니다.Flow 종류부터 구분하기Salesforce의 Flow는 크게 다섯 가지 유형이 있습니다. 어..

Salesforce 개발 및 설정 작업을 Sandbox에서 마치고 나면 운영 환경(Production)에 배포하는 과정이 남습니다. 이때 가장 많이 사용하는 방법 중 하나가 Change Set입니다. 클릭 몇 번으로 메타데이터를 패키징해서 올릴 수 있어서 직관적으로 느껴지지만, 실제로 배포를 진행하다 보면 생각지 못한 오류나 누락이 생기는 경우가 많습니다. 이번 글에서는 Change Set 배포 과정에서 자주 마주치는 문제와 사전에 예방하는 방법을 정리해보겠습니다.Change Set이란Change Set은 Salesforce 조직 간에 메타데이터(커스텀 오브젝트, 필드, 레이아웃, 플로우, Apex 클래스 등)를 이동시키는 선언적 배포 도구입니다. 배포 방향은 항상 Sandbox → Production ..

Salesforce에서 이메일 자동화를 구성하고 테스트해보면, 분명히 설정은 다 된 것 같은데 이메일이 도착하지 않는 경우가 생각보다 자주 있습니다. 오류 메시지도 없이 조용히 실패하거나, Sandbox에서는 됐는데 운영 환경에서 안 되거나, 특정 수신자에게만 안 가는 등 패턴도 다양합니다. 이번 글에서는 Salesforce 이메일 발송 설정의 전체 구조와 함께, 이메일이 가지 않을 때 원인을 찾는 방법을 단계별로 정리해보겠습니다.Salesforce 이메일 발송 구조 먼저 이해하기Salesforce에서 이메일이 발송되기까지 거치는 주요 설정 레이어는 세 가지입니다.Email Deliverability 설정. 조직 전체에서 이메일을 발송할 수 있는지를 제어하는 최상위 스위치입니다. Setup → Deliv..

Salesforce를 한국어로 운영하다 보면 반드시 한 번은 마주치는 작업이 있습니다. 커스텀 오브젝트나 커스텀 필드를 만들고 나면, 레이블이 영어 또는 개발자가 입력한 이름 그대로 화면에 노출됩니다. 이를 한국어로 바꾸는 데 사용하는 것이 Translation Workbench입니다. 설정 화면에서 직접 한 건씩 입력할 수도 있지만, 레이블 수가 많다면 파일로 일괄 내보내기(Export) → 번역 작업 → 가져오기(Import)하는 방식이 훨씬 효율적입니다. 그런데 이 파일 기반 작업 과정에서 예상치 못한 오류가 꽤 자주 나옵니다. 이번 글에서는 Translation Workbench의 기본 흐름과 함께, 실제로 자주 마주치는 문제와 해결 방법을 정리해보겠습니다.Translation Workbench ..

Salesforce 도입 프로젝트에서 승인 프로세스(Approval Process)는 언뜻 단순해 보입니다. "결재가 나면 Stage를 바꾸고, 반려되면 되돌리면 되지 않나요?" 실제로 구현해보면 생각보다 고려해야 할 것이 많습니다. 승인 단계가 여러 개이거나, 조건에 따라 경로가 달라지거나, 승인 알림을 특정 방식으로 받아야 한다면 설계 단계에서 구조를 잘 잡아두지 않으면 나중에 수정 비용이 커집니다. 이번 글에서는 실제 프로젝트에서 승인 프로세스를 설계하며 정리한 포인트를 공유합니다.승인 프로세스의 기본 구조 이해하기Salesforce의 승인 프로세스는 크게 다섯 가지 구성 요소로 이루어져 있습니다.진입 조건(Entry Criteria). 어떤 레코드가 이 승인 프로세스의 대상이 되는지를 정의합니다...

Salesforce를 도입할 때 기능 구현만큼이나 중요한 것이 누가 어떤 데이터를 볼 수 있는가를 설계하는 일입니다. 영업 조직이라면 담당자가 자기 고객 데이터만 봐야 하고, 관리자는 팀 전체를 봐야 하며, 협력사는 제한된 정보만 접근할 수 있어야 합니다. 이 모든 것을 규칙으로 만들어주는 것이 Salesforce의 레코드 공유 모델입니다. 그런데 이 모델은 레이어가 여러 겹으로 쌓여 있어서, 어느 하나만 잘못 설계해도 "보여야 할 데이터가 안 보인다"거나 "보이면 안 될 데이터가 보인다"는 문제가 생깁니다. 이번 글에서는 Salesforce 레코드 공유 모델의 계층 구조를 실무 관점에서 정리해보겠습니다.레코드 공유 모델의 네 가지 계층Salesforce의 레코드 접근 제어는 아래 네 가지 요소가 순서대..

Salesforce를 어느 정도 사용하다 보면 한 번쯈 들어보게 되는 이름이 있습니다. Salesforce Shield. "보안 강화 옵션"이라는 설명은 들었지만, 정확히 어떤 기능이 포함되어 있고, 우리 조직에 필요한지 판단하기가 쉽지 않습니다. 이번 글에서는 Salesforce Shield를 구성하는 네 가지 핵심 기능을 실무 관점에서 정리합니다. 도입을 검토 중이거나, 고객사의 보안 요구사항에 대응해야 하는 분들께 도움이 되길 바랍니다.Salesforce Shield란Shield는 Salesforce의 기본 라이선스에 포함된 보안 기능 위에 추가하는 보안 강화 패키지입니다. 별도 라이선스로 제공되며, 금융·의료·공공 등 규제 산업에서의 컴플라이언스 요구를 충족하거나, 민감한 데이터를 다루는 조직의 ..

Salesforce 도입 프로젝트에서 빠지지 않고 등장하는 요구사항이 있습니다. "Outlook이랑 연동되나요?" 대부분의 영업 담당자들은 Salesforce보다 Outlook을 더 오래, 더 자주 씁니다. 이메일과 일정 데이터가 Salesforce에 자동으로 반영된다면 수기 입력 부담이 크게 줄어드는 것은 분명합니다. 문제는 Salesforce가 Outlook 연동 방식을 하나가 아니라 두 가지 제공하고 있다는 점입니다. Outlook Integration(Add-in 방식) 과 Einstein Activity Capture(EAC) 는 이름은 비슷해 보여도 작동 원리, 필요한 설정, 라이선스, 그리고 실제 사용자 경험이 꽤 다릅니다. 이 둘을 혼동하면 도입 후에 예상치 못한 문제를 마주할 수 있습니다..