Data-Architect 문제 131

한 대형 자동차 제조업체는 Salesforce를 CRM으로 사용하기로 결정했습니다. CRM에서 다음 딜러 유형을 유지해야 합니다.
지역 딜러
지역 대리점
주 대리점
서비스 딜러
속성은 고객 유형마다 다릅니다. CRM 사용자는 고객 유형과 관련된 속성만 입력할 수 있어야 합니다. 각 고객 유형에 대한 프로세스와 비즈니스 규칙은 다를 수 있습니다.
Salesforce에서 다양한 딜러를 어떻게 유지해야 합니까?

Data-Architect 문제 132

UC에는 지역 지점에 분산된 여러 SF 조직이 있습니다. 각 지점은 조직의 계정 및 연락처 개체 내에 로컬 고객 데이터를 저장합니다. 이로 인해 UC가 모든 조직의 고객을 볼 수 없는 시나리오가 생성됩니다.
UC는 모든 조직의 계정 및 연락처 데이터를 한 곳에서 보고 싶어하므로 고객에 대한 360도 뷰를 생성하는 계획을 가지고 있습니다.
고객에 대한 이러한 360도 뷰를 달성하기 위해 데이터 설계자는 무엇을 제안해야 합니까?

Data-Architect 문제 133

Universal Containers(UC)는 Salesforce를 사용하여 기회(Opportunity)를 추적합니다. UC는 배송 추적 및 송장 발행을 위해 내부 ERP 시스템을 사용합니다. ERP 시스템은 Salesforce와 ERP 시스템 간의 양방향 통합을 위해 SOAP API 및 OData를 지원합니다. UC에는 약 백만 개의 기회가 있습니다. 각 기회에 대해 UC는 한 달에 하나씩 12개의 송장을 보냅니다. UC 영업 담당자에게는 기회 페이지에서 현재 송장 상태와 송장 금액을 확인해야 하는 요구 사항이 있습니다. 송장을 모델링하기 위한 객체를 생성할 때 성능과 데이터 저장 공간을 고려하여 건축가가 권장해야 할 사항은 무엇입니까?

Data-Architect 문제 134

Universal Containers(UC)에는 주요 계정 내의 부서를 나타내는 다단계 계정 계층이 있습니다. 사용자가 여러 부서에 중복된 연락처를 만들고 있습니다. UC는 여러 부서에 걸쳐 단일 연락처를 갖도록 데이터를 정리하려고 합니다. UC가 데이터를 정리하기 위해 구현해야 하는 두 가지 솔루션은 무엇입니까? 답변 2개 선택

Data-Architect 문제 135

NTO는 판매 사용자를 위해 Salesforce를 구현했습니다. Salesforce의 기회 관리는 다음과 같이 구현됩니다.
1. 영업 사용자는 예측 및 보고 목적으로 Salesforce에 기회를 입력합니다.
2. NTO에는 매일 기회에 대한 기회 금액 필드를 업데이트하는 데 사용되는 제품 가격 책정 시스템(PPS)이 있습니다.
3. PPS는 NTO 내에서 기회 금액에 대한 신뢰할 수 있는 소스입니다.
4. NTO는 판매 계획 및 관리를 위해 기회 예측을 사용합니다.
영업 사용자는 PPS가 기회를 업데이트할 때 기회 금액 필드에 대한 업데이트가 덮어쓰여지는 것을 확인했습니다.
데이터 설계자는 이 중요한 문제를 어떻게 해결해야 합니까?