밑에 보시면 Values라고 있어요. 여기에서 목록을 관리할 수 있는데요, 새로운 값을 추가하거나, 보여주는 순서를 바꾸거나, 기존에 어떤 값을 다른 값으로 교체하거나, 아니면 현재 목록을 인쇄할 수 있는 화면도 제공하고요. 추가로 챠트의 색상을 랜덤으로 할지, 각 필드에서 지정한 대로 고정으로 할지도 결정할 수 있습니다.
Active, Inactive, Deleted, and Replaced Values
위의 목록을 보시면 각 항목 앞에 Edit | Del | Deactivate을 클릭할 수 있게 되어 있습니다. 계절이 지난 맛은 Deactivate하거나 인기가 없는 맛은 Delete할 수 있습니다. 여러개 선택해서 상단에 버튼으로 한번에 처리할 수도 있어요.
Edit Picklist Values
위의 목록에서 아무 항목이나 Edit를 클릭해보시면, 기존 값을 변경할 수도 있고, 이 값을 디폴트로 만들거나 챠트에 색상을 지정할 수도 있습니다.
Why a Picklist Value’s API Name Is Important
현재 버젼의 Salesforce는 Picklist에서 항목을 선택했을때 Label이 아닌 API Name을 데이타베이스에 저장합니다. 그래서 API Name만 동일하다면 Label이 바뀌어도 로직에 문제가 없습니다. 여기서 만약에 API Name을 변경해버리면 기존 레코드는 기존의 값을 가지고 있기 때문에 기존 레코드들이 갈 곳을 잃어버리는 경우가 생깁니다. Label은 자유롭게 변경하되 API Name은 여러가지 부분에서 이미 사용되고 있기때문에 변경시 문제를 일으킬 가능성이 있기때문에 각별한 주의가 필요합니다.
Controlling Fields, Dependent Picklists, and Narrowing Values
Setup > Object Manager > Product > Fields & Relationships > Macaron Flavor > Field Dependencies > New에서 Controlling Field와 Dependent Field를 설정하여 생성할 수 있습니다.
Use Formulas for Default Picklist Values
Setup > Object Manager > Product > Fields & Relationships > Macaron Flavor > Edit > General Options > Show Formula Editor를 클릭하면 수식을 넣을 수 있는 화면이 열립니다.
Formula의 가장 기본적인 기능은 주어진 상황에 맞춰서 디폴트선택값을 알아서 착착 선택해서 보여주는 것입니다. 예를 들면, 어떤 고객문의가 들어왔는데 우선순위가 높으면 선배님에게 할당하고, 우선순위가 높지 않으면 후배님에게 할당하도록 한다고 치면 아래와 같이 공식을 만들 수 있습니다.
IF(Priority__c = "높음", "선배님", "후배님")
아니면, 어떤 진상고객이 있는데 그 고객을 김대리한테 할당하고 다른 사람이면 선택안한 상태로..
IF($User.Profile.Name = "오진상", "김대리", null)
날짜기반으로도 선택 기본값을 바꿀 수 있습니다. 마케팅 캠페인이나 분기별 기본값 설정 시 유용합니다.
Change the Field Type to Allow/Prevent Multi-Selection
Field Edit화면의 상단에 Change Field Type버튼을 클릭하면 해당 필드의 Data Type을 변경할 수 있습니다. 예를 들어 여러가지 맛을 선택하게 하고 싶다면 Picklist(Multi-Select)로 바꿀 수 있는데 주의 하셔야할점은 데이타유형이 달라지면 값에 손실이 있을 수 있다는 겁니다. 이 방법은 별로 추천하지 않고요, 차라리 새로운 필드를 만드셔서 데이타타입 맞춰서 그쪽으로 복사하는게 더 안전하고 확실합니다.
Hands-on Challenge
You’ll be completing this unit in your own hands-on org. Click Launch to get started, or click the name of your org to choose a different one.
Your Challenge
Use a formula to define a default picklist value
As an administrator, you want the default value for the macaron flavor to be the flavor of the month for some months, otherwise the default is Vanilla.
Use the formula editor to set the Default Value for the Macaron Flavor picklist as follows: CASE(MONTH(TODAY()), 1, "Gingerbread", 2, "Strawberry", 4, "Chocolate", 7, "Raspberry", 11, "Pumpkin", 12, "Mint", "Vanilla")
풀이
Formula사용해서 기본 선택 목록 값 정하기
여러분 관리자로서 마카롱 맛의 기본값을 Vanilla(바닐라)로 설정하되, 특정한 달에는 그 달의 추천 맛을 별도로 설정하고자 합니다.
수식 편집기를 사용해서 Macaron Flavor(마카롱 맛) 선택 목록의 기본값을 다음과 같이 설정합니다. CASE(MONTH(TODAY()), 1, "Gingerbread", 2, "Strawberry", 4, "Chocolate", 7, "Raspberry", 11, "Pumpkin", 12, "Mint", "Vanilla")
어떤 필드는 값을 입력할때 드롭박스를 제공해서 정해진 목록중에 하나를 선택하게 하잖아요. 우리도 때로 필드의 데이타 타입을 Picklist로 만들어야할때가 있어요. 이번 시간에는 기존에 Salesforce에서 제공하는 Standard Picklist와 우리가 만들어서 사용하는 Custom Picklist, 그리고 한번에 다중선택을 가능하게 해주는 Custom Multi-Select Picklist에 대해서 알아보겠습니다.
Standard Picklist
Standard Picklist는 Salesforce에 원래 포함되는 목록입니다. 예를들면, Lead 개체의 Lead Source 선택 목록, Opportunity 개체의 Opportunity Stage 선택 목록 등이 있습니다.
Custom Picklists
어떤 필드를 Custom Picklist로 생성하려면, Object에 들어가서 Fields & Relationships에 들어가서 New버튼을 누르고, Data Type에서 Picklist를 선택하고, Value에 줄바꿈으로 구분하여 선택할 항목들을 나열하면 사용자가 해당 필드에 데이타를 입력할때 나열한 목록 중 하나를 선택하도록 유도하게 됩니다.
목록은 알파벳 순으로 보여줄 수도 있고, 첫번째 항목을 디폴트값으로 정할수도 있고, Restrict picklist to the values defined in the value set체크박스를 활성화 시켜서 나열된 목록의 값 이외의 값을 허용하지 않도록 설정할 수도 있습니다.
Custom Multi-Select Picklists
선택상자 만들때 하나만 선택하게 하는게 있는가하면 여러개 선택할 수 있는 것도 있잖아요. 필드 생성하실때 Picklist 바로 밑에 있는 Picklist (Multi-Select)라는 애를 선택하면 하나 이상의 값을 선택할 수 있어요. 여러개 선택했을때는 값이 세미콜론으로 구분되서 들어가서 보여줄때는 다시 다중선택상자에 값을 선택해서 보여줍니다.
Restricted Picklists
위에서 잠깐 언급했던 Restrict picklist to the values defined in the value set를 선택하지 않으면 나열된 값 이외의 값이 들어갈 여지가 있어요. Salesforce UI를 이용할때는 선택상자에서 값을 선택해야하니까 다른 값이 들어올 일이 없지만 API를 직접호출하거나 API를 이용한 다른 앱이 다른 값을 입력하는 것을 허용한 경우에 다른 값을 저장하도록 허용하게 됩니다. 만약 나열한 값들만 반드시 넣어야한다면 Restrict picklist to the values defined in the value set를 체크해주세요. 그러면 API에서 호출을 한 경우에도 해당 목록이외의 값은 저장하지 않도록 검증을 합니다.
그 값은 필드에서 임의로 목록에 나열을 했든, Global value set에서 목록을 정했든 상관없이 해당 필드에 Restrict picklist to the values defined in the value set가 ON이라면 지정한 목록에 있는 값 이외의 값은 저장 할수 없게됩니다.
Dependent Picklists
이건 종속 선택목록이라고 하는건데요. 예를 들면 산본동을 선택하고 싶은데 우리나라에 동이 엄청 많은데 그롭박스에서 산본동을 찾으려면 스크롤을 많이 내려야할거에요. 그리고 산본동이 다른 시/도에도 있을 수 있잖아요. 그래서 우리는 먼저 시/도를 선택하고 구를 선택하고 그다음에 동을 선택하게 됩니다. 이때 시/도를 선택하면 다음 선택상자에는 해당 시/도에 있는 구만 보여주고 구를 선택하면 동에 해당하는 선택상자에는 해당 구 안에 있는 동만 보여주게 되어서 선택이 더욱 정확하고 용이하게 됩니다.
Compare Picklist Fields
Standard Picklist
Custom Picklist
Custom Multi-Select Picklist
Add/Remove from Page Layouts
Yes
Yes
Yes
Delete from Your Org
Yes
Yes
Set a Default Value
Yes
Yes
Yes
Use a Formula for a Default Value
Yes
Yes
Can Select Multiple Values
Yes
Can Add Values via Apps or API
Yes
Yes
Yes
Can Be Restricted
Yes
Yes
Can Be a Dependent Picklist
Yes
Yes
Hands-on Challenge
Create a custom picklist
You work for a cookie store. You sell lots of macarons. What’s a macaron? A macaron is a cookie that comes in many flavors. So, your customers have a lot of choices.
Add a picklist field to the standard Product object with the following settings:
Object: Product
Field Type: Picklist
Field Label: Macaron Flavor
Field Name: Macaron_Flavor
Make sure Restrict picklist to the values defined in the value set is selected
Include the following picklist values:
Gingerbread
Strawberry
Chocolate
Raspberry
Pumpkin
Mint
Vanilla
Make this field visible to all user profiles
풀이
오늘 도전과제에서는 Custom picklist를 생성할거에요.
오늘 당신은 쿠키가게에서 일합니다. 아주 많은 마카롱을 팔아야해요. 마카롱은 엄청 다양한 맛이 있잖아요. 그래서 고객들은 어떤 맛을 먹을지 선택하게 해드릴게요.
일단 새로운 단원의 첫번째 과제니까 새로운 Playgound(Picklist)를 생성할게요.
어떤 Object의 기본 접근이 Private이면 해당 레코드는 소유자 + 상위역할계층에 있는 사용자만 볼수 있어요. 그런데 여업팀 전체가 볼 수 있어야 하는 상황이라면 Sharing Rule을 만들어서 그 팀에 열어줄 수 있습니다.
공유 규칙을 세울때는
어떤 레코드를 공유할지
특정 Owner가 소유한 레코드
필드값을 기준으로 레코드 선택가능
누구와 공유할지
개별사용자
Role
Role + 하위역할
Territory
Territory + 하위역할
혹은 Public Group
어떤 권한을 줄지
Read-Only
Read/Write
Public Group은 관리자가 필요에 따라 만든 사용자 그룹인데 역할이나 프로필이 서로 다른 사람들을 하나도 묶어야 하는 경우에 만들어서 사용합니다. Sharing Rule을 만들기 전에 Public Group을 우선적으로 만들어서 Sharing Rule에서 사용하는게 만들기도 쉽고, 나중에 유지보수도 쉬워집니다. 조직이 바뀔때 나중에 Public Group만 수정하면 되거든요.
Recruiting App에서의 Sharing Rules
Sharing Rule은 관리자가 미리 정적으로 정의할 수 있으면 규칙을 만들 수 있고, 레코드가 매번 임의로 달라지면 Sharing Rule로는 규칙을 만들 수 없고 다른 방법으로 권한을 줘야해요. Sharing Rule은 자동 + 일괄로 적용이 되야 하거든요.
Sharing Rule은 보통 모든 레코드를 어떤 그룹이나 역할에 속한 사람 전부에게 항상 동일한 조건으로 접근 권한을 주어야 할때 사용합니다. 누가 대상인지가 미리 고정이 되어야 가능해요.
만약 레코드마다 대상 사용자가 바뀌거나, 같은 객체에서 이 레코드에서는 이사람, 저 레코드에서는 다른사람이 권한을 가져야하는 상황인데 나중에 그게 누가 배정될지 모르는 상황이라면 Sharing Rule로 권한을 주기에는 어려운 부분이 있어요.
채용앱에서 어떤것이 Sharing Rules로 만들 수 있는 것인지 생각해볼게요
Recruiters
Read/Write
Position
Candidate
Job application
Review
Yes. Recruiters들은 구인관련해서 모든 포지션, 모든 지원자, 그리고 모든 지원서와 리뷰상황등을 전부다 볼 수 있어야합니다.
Hiring Managers
Read/Write
Position
No. Hiring Managers에 들어간 모든 사람이 모든 Position에 읽고 쓰기가 가능하면 안되요. 오직 자기가 관리하는 포지션만 쓸수 있어야해요. 그런데 포지션이 열릴때마다 Hiring Manager는 매번 바뀌기 때문에 자동으로 예측하고 미리 규칙을 정해놓는 것이 불가능합니다. 이건 매번 포지션이 나올때마다 수동으로 Hiring Manager를 지정해주어야 하기 때문에 미리 Sharing Rule을 만들 수 없어요.
Read
Candidate
No. Cadidate은 Position에 묶여 있지 않아서 어떤 지원자를 Hiring Managers들이 봐도 되는지 안되는지는 나중에 그 지원자의 Position이 결정되면 그때 알 수 있어요. 한명의 지원자가 여러개의 포지션에 지원할 수도 있는 거잖아요. 그래서 모든 Hiring Manager들이 전부 모든 Candidate을 볼수 있게 할 수는 없어요.
Read/Write
Job Application
Review
Yes, Cadidate과는 달리 Job Application이나 Review는 정보 입력시에 Position에 항상 정해져있어요. 그래서 어떤 Hiring Manager에게 보여줄지를 미리 정할 수 있습니다.
Interviewer
Read
Candidate
Job Application
No, 어느 포지션을 누가 면접볼지는 미리 결정 할 수 없으므로 공유규칙 불가능
Object
Label
Target
Level
Review
Edit Reviews
Recruiters & Hiring Managers
Read/Write
Job Application
Edit Job Applications
Recruiters & Hiring Managers
Read/Write
Candidate
Edit Candidates
Recruiting Manager + 하위역할
Read/Write
Position
Edit Positions
Recruiting Manager + 하위역할
Read/Write
Create a Public Group
Setup > Quick Find > Public Groups > New
Label: Reviewers
Save
Public Groups > Reviewers > View Summary
All Public Group Members 에서 Add Members를 클릭해주세요.
각 탭에 개별 사용자, 역할별, 영역별 등 다양한 조합의 사용자 그룹을 선택할 수 있습니다. 아래 역할을 추가해주세요.
Role: SW Dev Manager
Role: Director Product Management
Role: Director QA
Role and Internal Subordinates: Recruiting Manager
Save
Define a Sharing Rule
Setup > Quick Find > Sharing Settings
Manage sharing settings for: Review
Sharing Rules > New
Rule Name
Label: Edit Reviews
Select your rule type
✅ Based on record owner
Select which records to be shared
Public Groups > All Internal Users
Select the users to share with
Public Groups > Reviewers
Select the level of access for the users
Read/Write
Save
Message
The recalculation of sharing access will continue in the background. You’ll receive an email notification upon completion. Do you want to continue?
OK
Hands-on Challenge
Create a Sharing Rule for the Program Object
The Program object has an org-wide default of Private, but recruiters need access to any Campus Outreach programs for recruitment purposes. Create a custom picklist field on the Program object, then create a criteria-based sharing rule to share the necessary records with the recruiters.
Get help on the challenges for this specific module.
Before You Start
Make sure you complete the hands-on challenges in the previous units of this module before you attempt this challenge. The work you do here builds on work you do in those units.
If you haven’t created a custom field before, complete the Data Modeling module before you attempt this challenge.
Create a custom field for the Program object:
Field Type: Picklist
Field Label: Type복사
Field Name: Type복사
Values (each value separated by a new line):
Campus Outreach복사
Development복사
Research복사
On the field-level security page, set this field as Visible for all profiles or as Read Access for all permission sets. (This step assures the challenge passes.)
Create a sharing rule for the Program object:
Label: Campus Outreach Programs
Rule Name: Campus_Outreach_Programs복사
Rule Type: Based on criteria
Field: Type
Operator: equals
Value: Campus Outreach
Share with (role): Recruiter
Access level: Read/Write
풀이
Program객체에 대해서 Sharing Rule을 만들어주세요.
Program객체는 OWD에서 Private으로 권한이 설정되어 있습니다. 그런데 Recruiters들이 Campus Outreach Programs에 대한 접근 권한을 요구합니다. Program객체에 picklist타입으로 필드를 하나 만들고 Campus Outreach Programs랑 다른 프로그램도 넣을 수 있게 한뒤, criteria-based sharing rule을 만들어서Campus Outreach Programs에 해당하는 레코드만 Recruiters들과 공유하세요.
이전 강좌들의 도전과제를 완료하지 않았다면 본 과제를 완료할 수 없습니다.
Program객체를 생성해주세요
Setup > Object Manager > Create > Custom Object
Label: Program
Plural Label: Programs
Save
Program객체에 아래의 필드를 추가해주세요
Setup > Object Manager > Program > Fields & Relationships > New
Step 1. Choose the field type
Data Type: Picklist
Step 2. Enter the details
Field Name: Type
✅ Enter values, with each value separated by a new line
Campus Outreach Development Research
Step 3. Establish field-level security
모든 Permission Sets에 Read Access
Program객체에 Sharing Rule을 생성하세요.
Setup > Quick Find > Sharing Settings
Manage sharing settings for: Program
Sharing Rules > New
Step 1. Rule Name
Label: Campus Outreach Programs
Rule Name: Campus_Outreach_Programs
Select your rule type
Based on criteria
Select which records to be shared
Field: Type
Operator: equals
Value: Campus Outreach
Select the users to share with
Roles > Recruiter
Select the level of access for the users
Access level: Read/Write
Save
Message
The recalculation of sharing access will continue in the background. You’ll receive an email notification upon completion. Do you want to continue?
이번 시간에는 조직의 계층별로 데이타에 접근하는데 권한에 차등을 두어 윗사람은 아랫사람의 데이타를 보고 아랫사람은 동료나 윗사람의 데이타를 볼 수 없는등의 설정을 하도록 하겠습니다.
Define Role Hierarchy
역할계층 구조를 보기 위해서 Setup > Quick Find > Roles > Set Up Roles를 클릭하세요.
Organization’s Role Hierarchy페이지 우측에 보면 드롭박스가 있는데 이는 3가지 화면 구성을 제공합니다. 가장 먼저 보이는 화면 구성은 Tree View이고 계층적 구조를 한눈에 파악할 수 있어서 편리합니다. 그리고 Show in sorted list view는 알파벳순으로 볼 때 편리하고, Show in list view는 목록형태로 보여주돼 Depth를 주어서 소속관계를 한눈에 파악 할 수 있습니다. 우측 드롭박스를 클릭하셔서 다양한 뷰의 형태를 직접 사용해 보시기 바랍니다.
들어가자마자 보이는건 Tree View입니다. Expand All을 클릭해서 전체 역할 계층을 한눈에 확인 할 수 있습니다.
본 유닛에서 VP Human Resources에 Onboarding Manager을 추가하라고 하는데 VP Human Resources가 Roles에 존재하지 않아요. 그래서 VP Human Resources를 먼저 추가하고 계속 진행하도록 하겠습니다.
Tree view에서 SVP, Human Resources를 찾아주세요.
그 바로 아래에 있는 Add Role버튼을 클릭해주세요.
Label: VP Human Resources
Role Name: VP Human_Resources
This role reports to: SVP, Human Resources
Save
이제 Onboarding Manager Role을 추가해볼게요
Tree view에서 VP Human Resources를 찾아주세요.
그 바로 아래에 있는 Add Role버튼을 클릭해주세요.
Label: Onboarding Manager
Role Name: Onboarding_Manager
This role reports to: VP Human Resources
Save
길이가 긴 역할 이름은 보고서 열에서 추가 공간을 차지하므로 Role Name as displayed on reports에 짧지만 읽기 쉬운 약어를 사용하는 것이 좋습니다
새로 추가한 Role에 사용자를 할당해 볼게요.
현재 화면(Roles > Onboarding Manager)에서 Assign Users to Role버튼을 클릭해주세요.
Available Users에서 All Unassigned를 선택하면 역할이 정해지지 않은 사용자들이 보입니다.
목록에서 사용자를 선택하고 Add버튼을 누르면 Selected Users for Onboarding Manager로 사용자가 들어갑니다.
Save버튼 클릭하고 나오면 하단에 추가된 사용자가 보일거에요.
Hands-on Challenge
Create the Role Hierarchy for the Human Resources Department
Finish setting up the Recruiting Manager and Recruiter roles. Remember that the VP Human Resources can see records owned by or shared to users in the Recruiting Manager role. And Recruiting Managers can see the data that Recruiters can access.
Get help on the challenges for this specific module.
Create the Recruiting Manager role:
Label: Recruiting Manager
Role Name: Recruiting_Manager
Reports to: VP Human Resources
Create the Recruiter role:
Label: Recruiter
Role Name: Recruiter
Reports to: Recruiting Manager
풀이
인사팀에 역할계층을 생성합니다.
Recruiting Manager를 생성하고, Recruiting Manager가 만든 데이타나 Recruiting Manager에게 공유된 데이타는 VP Human Resources가 전부 볼수 있어야합니다. 그리고 Recruiting Managers는 Recruiters가 접근할 수 있는 모든 데이타를 볼 수 있어야합니다.
To control data access precisely, you can allow particular users to view specific fields in a specific object, but then restrict the individual records they’re allowed to see. Record access determines which individual records users can view and edit in each object they have access to. First ask yourself these questions:
데이터 액세스를 정확하게 제어하기 위해 특정 사용자가 특정 개체의 특정 필드를 볼 수 있도록 허용하되, 볼 수 있는 개별 레코드를 제한할 수 있습니다. 레코드 액세스를 통해 사용자는 액세스할 수 있는 각 개체에서 보고 편집할 수 있는 개별 레코드를 결정할 수 있습니다. 먼저 다음 질문을 해보세요.
데이타접근을 좀더 세부적으로 제한하는 방법에는 특정 사용자가 특정 개체나 그 개체의 특정 필드를 볼 수 있도록 허용을 하는 방법에 대해서 배웠는데요, 이제는 레코드 마저도 어떤 레코드를 볼 수 있게 할지 편집은 하게 할지 말지를 결정할 수 있습니다. Record Access를 통해서 어떤 사용자가 어떤 데이타를 보고, 또는 편집할 수 있는지 등을 결정하게 됩니다.
레코드 단위 접근제한 방법
레코드 단위로 접근을 제한 하는 방법에는 4가지가 있습니다:
Organization-Wide Defaults (OWD)
조직내 모든 사용자에게 부여되는 기본적인 접근권한입니다.
보통 가장 제한적으로 설정하고 필요에 따라 권한을 할당하는 식으로 관리합니다.
Role Hierarchy (역할 계층)
회사 조직 구조처럼 상사하 아랫사람의 레코드를 자동으로 볼수 있게 합니다.
Sharing Rules (공유규칙)
특정 사용자 그룹이나 역할에 대해 레코드를 자동으로 공유합니다.
OWD에 권한이 없어서 접근이 안될때 권한을 부여하기 위해 사용합니다.
Manual Sharing (수동공유)
레코드를 소유한 사람이 다른 사용자에게 특정 레코드를 공유할 수 있습니다.
규칙에 따라 자동으로 공유가 되는 것이 아니고 특별한 경우에 예외적으로 사용하는 방법입니다.
Org-Wide Sharing Defaults
Setup > Quick Find > Sharing Settings
Organization-Wide Defaults 안에 보면 Edit버튼이 있습니다. 클릭하시만 아래와 같은 화면이 뜨는데요. 여기에서 Default Internal Access와 Default External Access를 설정하실 수 있으세요.
아래처럼 변경해주세요:
Default Internal access
Position: Public Read Only
Candidate: Private
Job Application: Private
Review: Private
Default external access
Position: Private
Candidate: Private
Job Application: Private
Review: Private
Save
참고로, OWD에서 Default로 선택할 수 있는 선택지는 객체마다 다를 수 있습니다. 어떤 객체는 더 많은 옵션을 가지기도 하고 어떤 객체는 아예 Controlled by Parent 같은 특수 옵션이 있기도 하고 어떤 표준 객체는 Private를 지원 안 할 수도 있고 어떤 건 Public Read Only만 있기도 합니다. Custom Object는 OWD옵션이 항상 3개(Private, Public Read Only, Public Read/Write)로 고정입니다. Controlled by Parent나 Public Read/Write/Transfer같은 옵션은 표준객체에만 제공되는 옵션입니다.
Role Hierarchy를 통해 상위 역할(매니저)는 하위 역할(부하 직원)의 레코드를 자동으로 볼수 있어요. 하지만 이걸 막고 싶을때 Grant Access Using Hierarchies 체크박스를 해제 하면 레코드의 소유자와 각종 접근 규칙으로 권한을 부여받은 사람만 접근이 가능하고 상사라고해서 부하직원 파일을 볼수 있고 그런게 없어져요.
OWD를 변경하면 자동으로 Sharing Recalculation이 실행되서 기존에 있던 레코드들에 대해서 누가 볼수 있고, 누가 수정할 수 있는지 다시 계산을 합니다. 이때 Salesforce가 백그라운드 작업을 돌리게 됩니다.
OWD에서 권한을 너무 짜게 줘서 활동에 제한이 있을수 있어요. 그럴때는 위에서 소개한 Record-Level Security의 다음 단계들을 설정해서 권한을 열어주도록 합니다.
Hands-on Challenge
Configure Organization-Wide Defaults
For the Recruiting app, you must create a custom object to track referrals for positions. Referral records by default should be visible only to the record owner and shouldn’t be visible to users above the owner in the role hierarchy. Create the Referral custom object, then update the organization-wide default sharing setting for the Referral object.
회사 직원들의 이름과 전화번호는 모든 직원들에게 공유되어도 되지만 연봉같은 정보는 특정 사람들에게만 보여주어야하고, 입사지원자들의 이력서는 채용에 가담하는 모든 사람들이 볼 수 있어야하지만 SSN같이 예민한 정보는 숨겨야하는 경우가 있잖아요. 그럴때 Object단위가 아닌 Field단위로 권한을 제한 할 수 있습니다.
자세한 설명은 나중에 하겠지만 오해를 만들지 않기 위해서 한가지 짚고 넘어 가자면, 일부 Field permissions는 항상 활성화되어 있으며 Permission Sets이나 Profile에서 그 권한을 수정할 수 없습니다.
Permission Set에 필드권한 주기
지난 시간 사용했던 채용앱에서 입사지원자들의 면접이 끝났다고 쳐요. 그러면 면접관들이 지원자들에 대한 면접결과를 입력해야하는데 이때 필요한 정보를 읽는 것을 허용하고, 필요한 필드들을 수정하는 것을 허용하도록 Permission Set을 만들어 보도록 할게요.
Job Category필드가 Update Candidate Records Permission Set에서 읽고 편집이 가능하도록 Read Access와 Edit Access의 체크박스를 ✅체크합니다.
Save
Hands-on Challenge
Create a Permission Set to Handle Field Access
One of the requirements of our Recruiting app is that Hiring Managers can update job applications, but they can’t change the related candidate or position. Create a permission set that gives the correct access.
Get help on the challenges for this specific module.
Create a permission set:
Label: Manage Job Applications
API Name: Manage_Job_Applications
Add a description (We won’t check for this.)
License: -None-
Enable Job Application Object Permissions: Read and Edit
Enable Job Application Field Permissions: Assigned users can view all fields and edit all fields, except they can’t edit Position and Candidate.
풀이
Handle필드에 접근하기위한 Permission Set생성하기
Hiring Manager가 지원서를 편집할 수 있게 해주세요. 단, Related candidate이나 Position필드는 변경할 수 없게 해주세요.
여기서 우리는 작업을 담당하는 Permission Set과 사람을 담당하는 Permission Set Group을 만들거에요. Permission Set에는 Job Application을 관리하는 권한을 부여하고, Hiring Manager Permission Set Group을 만들어서 에 해당 Permission Set을 추가할거에요.
Job Application의 Candidate(Lookup)과 Position(Lookup)이 두가지 필드를 삭제하고 다시 생성한 뒤 계속 진행할게요.
Candidate과 Position레코드의 맨 뒤에 드롭박스에서 Delete버튼을 클릭해서 두개다 삭제해줍니다.
New버튼을 클릭해서 Custom Field로 다시 만들어 줍니다.
Data Type: Text
Field Label: Candidate
Length: 10
Next, Next, Save
New버튼을 클릭
Data Type: Text
Field Label: Position
Length: 10
Next, Next, Save
위의 두개 필드를 다시 생성해주는 이유는 아래 Permission Set에서 권한을 제거해야하는데 두개 필드가 System Field라서 선택상자가 비활성화 되어 있어서 체크를 해지할 수 없기 때문에 과제가 완료가 되지 않습니다. 그래서 해당 필드들을 Custom Field로 임의로 변경해서 나중에 체크를 해제할 수 있도록 하기 위함이에요.
지원서를 관리할 수 있는 Permission Set을 만들게요
Setup > Permission Sets > New
Label: Manage Job Applications
API Name: Manage_Job_Applications
Description: This is a permission set to manage job applications
그리고 Field Permissions의 모든 필드에 Read Access와 Edit Access를 부여하되, 단 Position과 Candidate필드 두개는 편집권한을 부여하지 않습니다. 아까 우리가 필드를 Custom Field로 바꾸지 않았다면 아래와 같이 해당 체크박스가 비활성화가 되어서 선택을 해지할 수 없게 되어서 도전과제에 실패하게 됩니다.
Save버튼을 클릭해서 도전과제를 완료합니다.
참고로 도전과제에서 Position과 Candidate필드는 제외하고 나머지 Field Permissions를 모두 권한을 부여하라고 지시하고 있는데요. Position과 Candidate은 체크가 비활성화 되어있어서 체크를 없앨수가 없어요. 그런데 어차피 System Field라서 누구도 조작이 불가능합니다. 그래서 이대로 체크를 내버려 두고 진행을 하시면 될것 같아요.
여기까지가 도전과제였지만 사실 이대로 서비스를 할 수는 없으니까 서비스 하는 차원에서 마무리를 해볼게요. 이하 내용은 제가 임의로 연습하는 거니까 도전과제의 일부는 아니에요.
이제 Permission Set Group을 만들고 방금 만든 Permission Set을 추가할게요.
Setup > Permission Set Groups > New Permission Set Group
Label: Hiring Managers
API Name: Hiring_Managers
Description: This is a permission set group for the hiring managers
Salesforce에서 객체는 데이터 저장 단위입니다. 예를 들어 Account, Contact, Lead 같은 것이 객체입니다. 이 모듈에서는 사용자가 특정 객체를 Create, Read, Edit, Delete 할 수 있는지를 제어하는 법을 배웁니다.
Installation
진행을 위해 Recruiting App 패키지를 설치해주세요.
Package ID: 04t0P000000N9rs
Learning Objectives
이 모듈을 완료하면 다음을 할 수 있어요:
Explain the difference between profiles, permission sets, and permission set groups.
Modify access to objects.
Clone and assign a profile.
Create and assign new permission sets.
Create and assign new permission set groups.
Manage Object Permissions
Profiles
사용자 기본 설정을 담고 있는 가장 기본적인 보안 설정 그룹
객체 권한, 페이지 레이아웃, 앱 접근 등 기본 액세스를 결정
한 사용자에 한 프로필만 할당 가능
Permission Sets
객체, 필드, 앱 등에 대한 권한을 추가로 부여할 때 사용
프로필보다 유연하고 재사용 가능
여러 퍼미션 세트를 한 사용자에게 할당할 수 있음
Permission Set Groups
여러 퍼미션 세트를 묶어서 한 번에 할당할 수 있게 함
예) Sales Rep, Recruiter 같은 직무 기반 그룹 생성 가능
퍼미션 세트들을 그룹으로 묶어서 관리 효율성 향상
실전 예시: Recruiting 앱 객체 접근
Custom Object
Recruiter
Hiring Manager
Interviewer
Standard Employee
Position
Read Create Edit
Read Create Edit*
Read (No min/max bonus)
Read (No min/max bonus)
Candidate
Read Create Edit
Read* (No SSN)
Read * (No SSN)
Not Applicable
Job Application
Read Create Edit
Read Edit (No lookup fields)
Read *
Not Applicable
Review
Read Create Edit
Read Create Edit
Read ** Create Edit **
Not Applicable
Profiles 설정
위에서도 언급했듯이 사용자는 오직 단 하나의 Profile만 가질 수 있어요. 사용자를 생성할때 Salesforce가 정한 몇가지 기본 프로필 중에 하나를 선택하게 되는데 이 종류는 다음과 같습니다:
Standard User
레코드를 만들고 편집
Object 권한을 편집할 수 없음
기존 프로필을 복제하고 이를 새 프로필의 기초로 사용하여 필요에 따라 설정을 조정할 수 있음
Marketing User
Contract Manager
System Administrator
데이터에 대한 가장 광범위한 액세스 권한
Salesforce를 구성 및 사용자 정의할 수 있는 가장 강력한 기능
모든 데이터 보기 및 모든 데이터 수정이라는 두 가지 특수 권한이 포함
Minimum Access – Salesforce
레코드를 볼 수 있지만 만들거나 편집할 수는 없음
가능하면 항상 최소 액세스 Salesforce 프로필(또는 그 복제본)을 사용한 다음 권한 집합 및 권한 집합 그룹을 사용하여 사용자에게 필요한 권한만 부여하는 것이 좋습니다.
프로필에서 이러한 기능을 구성하는 것이 좋습니다. – 기본 앱 및 레코드 유형 – IP 범위 – 로그인 시간 – 페이지 레이아웃 할당
Create and Assign a Profile
프로필을 만들어 볼건데요. 맨땅에 헤딩하는거 보다 기존에 프로필중에 하나를 선택해서 복사한다음 수정하는게 가장 쉬워요.
Profile을 생성하기 전에 Profile생성 화면을 탭별로 깔끔하게 보여주도록 변경하는 설정을 우선적으로 하고 넘어갈게요.
Setup > Quick Find > User Management Setting여기 가시면 여러가지 설정을 ON/OFF할 수 있는데요.
이중에 Enhanced Profile User Interface를 찾아서 활성화를 시켜주세요.
설정옵션 바로 밑에 설명대로 이 옵션을 활성화 하면 프로필에서 검색하고 수정할때 UI가 개선됩니다.
❌ ❌ ❌ Trailhead에서 시키는대로 User Management Setting에 가서 Enhanced Profile User Interface를 활성화 해주면 Profile에서 Edit버튼이 보이지 않아요.
Profile 복제하여 생성
Setup > Quick Find > Profiles에 들어가보시면 기존에 선언된 여러 Profile이 있는데요.
레코드 맨앞에 Clone을 클릭하면 해당 레코드를 똑같이 복제해서 하나 더 만들 수 있는데요.
Minimum Access – Salesforce를 찾아서 Clone버튼을 누릅니다.
그 다음 복사할 Profile의 새로운 이름만 넣어주고 Save버튼 누르면 복제가 완료됩니다.
복제된 Profile의 상세화면을 보여주네요
여기서 Edit버튼을 눌러서 각종 설정을 변경할 수 있습니다.
해당 Profile을 User에 할당하기
Setup > Quick Find > Users > testuser > Edit
Profile: Test Profile
Save
Permission Sets & Permission Set Groups
Permission Set / Permission Set Group을 사용하면 관리가 훨씬 편해집니다. 프로필만으로 권한을 관리하면 사용자마다 수많은 프로필을 만들어야 할 수도 있습니다. 반면 Permission Set + Permission Set Group 구조는 Lego 블록처럼 권한 조각을 조합해서 필요할 때마다 재사용할 수 있습니다.
Permission Set
Permission Set은 사용자에게 특정 권한들을 추가로 부여하는 설정입니다. 예를 들어, 어떤 사용자에게 “리드 관리 권한”, “리포트 생성 권한” 등 필요한 권한만 묶어서 줄 수 있습니다. Profile과 달리 한 사용자에게 여러 Permission Set을 부여할 수 있어 유연합니다. Permission Set은 프로필(profile)을 변경하지 않고도 권한을 보완할 수 있는 좋은 방법입니다.
Permission Set Group
Permission Set Group은 여러 Permission Set을 묶어놓은 그룹입니다. 즉, 여러 개의 Permission Set을 하나의 묶음으로 만들어서 그룹 단위로 사용자에게 할당할 수 있어 관리가 더 쉬워집니다. 이 그룹은 하나 이상의 Permission Set을 포함하며, 사용자가 이 그룹에 할당되면 그 안의 모든 권한을 자동으로 얻게 됩니다.
예를 들어: 영업팀과 마케팅팀 모두 리드 삭제(Delete) 권한이 필요하다고 해봅시다. 이때 “리드 관리” Permission Set 하나만 만들고, Sales 스택 그룹과 Marketing 스택 그룹에 이 Permission Set을 추가하면 됩니다. 나중에 수정이 필요할 때도 그 하나의 Permission Set만 변경하면 됩니다.
아래는 Permission sets에서 설정할 권한과 기능들입니다:
Apex classes
Apex 코드에 접근할 수 있는 권한
Apex Class = Salesforce에서 개발자가 만든 서버 로직
이 사용자가 특정 Apex 클래스를 실행할 수 있는지를 설정하는 것임
Lightning Component
Flow에서 Apex 호출
Custom Button / Automation 뒤에 Apex가 있을 때
Connected app access
외부 앱이 Salesforce에 접근하도록 허용
Connected App = Salesforce ↔ 외부 서비스 연결 (OAuth)
예시
Google, Slack, DocuSign
외부 모바일 앱
API 연동 툴
이 사용자가 어떤 Connected App을 사용할 수 있는지
이 유저가 이 외부 앱으로 로그인/연동해도 되는가? 하는 걸 설정함
Custom permissions
논리적인 권한 플래그
비즈니스 규칙용 스위치
UI 권한이 아니라 개발자가 쓰는 조건용 권한
Apex / Flow / Validation Rule에서 사용
예시
Can_Approve_Discount
Can_See_Internal_Notes
화면에서 버튼을 보이게 할지
특정 로직을 실행할지
승인 가능 여부 판단
Field permissions
필드 단위 접근 권한
객체 안의 개별 필드 설정 가능:
Read (보기)
Edit (수정)
예시
Salary 필드
HR: Read/Edit
일반 직원: No access
이 필드를 볼 수 있나? 수정할 수 있나?등을 설정
Object permissions
객체 단위 CRUD 권한
객체 전체에 대한 권한
설정 항목:
Create
Read
Edit
Delete
View All
Modify All
예시
Opportunity
Sales: Create/Edit
Support: Read only
이 객체로 레코드를 만들고/보고/수정/삭제할 수 있나?
User permissions (= App Permissions + System Permissions)
App Permissions
특정 Salesforce 기능 사용 권한
예:
Run Reports
Import Wizard
Access Activities
System Permissions
관리자급 기능
예:
Customize Application
Modify All Data
View Setup
Salesforce 기능 자체를 쓸 수 있느냐의 문제
Tab settings
탭이 보이느냐 안 보이느냐
설정 옵션:
Default On (항상 보임)
Default Off (숨김)
Tab Hidden (완전 숨김)
예시
Campaign 탭
마케팅팀: Default On
영업팀: Hidden
UI에 보이게 할지 말지
Visualforce pages
Visualforce 페이지 접근 권한
Visualforce = Salesforce의 구형 커스텀 UI 기술 설정
이 사용자가 어떤 VF 페이지를 열 수 있는지
언제 필요?
아직 VF 기반 페이지를 쓰는 조직
커스텀 버튼 / 링크가 VF로 연결될 때
Apex와 비슷하게 개발된 화면 접근 권한
항목
느낌
Object / Field
데이터 접근
User / Tab
기본 기능 & 화면
Apex / VF
개발 기능
Connected App
외부 연동
Custom Permission
조건 판단용
어떤 권한을 “없애려면” 그 권한이 들어 있는 모든 Permission Set 및 Group에서 다 제거해야 합니다. 여러개의 Permission Set를 사용자에게 부여했을때 나중에 준 권한이 이전 권한을 덮어쓰지 않기 때문에 사용자에게 부여된 Permission Set중 그 기능이 하나라도 켜져 있으면 권한은 살아 있게 되요. 마찬가지로 Profile에 들어있다면 거기서도 삭제를 해야 해당 권한이 없어짐.
채용 앱
채용 앱에는 4가지 사용자 유형이 있습니다.
채용 인사 담당자 (Recruiter)
채용 관리자 (Hiring Manager)
면접관 (Interviewer)
일반 직원 (Employee)
이들은 같은 객체를 쓰기도 하고, 권한 수준은 달라요. 그래서 Permission Set 재사용 + Permission Set Group 조합이 핵심 전략입니다.
채용 인사 담당자 (Recruiter)
Recruiter 전용 Permission Set Group을 만들어야 합니다. 왜냐면:
채용 인사 담당자는 채용 전반을 다 다루고,
접근 객체가 많기 때문이에요:
Review
Candidate
Position
Job Application
Recruiter Permission Set Group 에 묶을 Permission Set(객체)들
Review Object Permissions
Candidate Object Permissions
Position Object Permissions
Job Application Object Permissions
Recruiter니까 접근해야할 객체가 많고, 역할이 명확해서 Group으로 관리하는게 좋기때문에 Recruiter Permission Set Group으로 만들어야 한다고 판단이 되었습니다.
채용 관리자 (Hiring Manager)
채용 관리자는 각 팀의 팀장이나 팀장이 명시한 사람이 보통 담당하게 되는데 Hiring Manager Object Permission Set하나만 만들어서 여러 팀 관리자에게 재사용하도록 하는게 좋을 것 같음. 그 이유는:
부서마다 세부 데이터는 다를 수 있음
영업팀 vs 엔지니어링팀
하지만 객체 자체는 동일
Review
Candidate
Position 등
Object 권한만 공통 Permission Set으로 부여하고 필드 제한 / 레코드 제한은 나중에 처리하는게 좋다고 판단됨 객체 접근 = 공통 필드 / 레코드 차이 = 나중 문제
면접관 (Interviewer)
이 사람들은 모든 부서 직원이 될 수 있고 일시적으로만 채용 데이터 접근 필한 사람들입니다. 그래서 Interviewer Permission Set Group 생성하고 인터뷰 기간 동안만 할당했다가 끝나면 제거하는 식으로 하는게 좋을 것 같아요.
일반 직원 (Employee)
채용에 참여 안 해도 모든 사용자가 Position(직책)은 볼수 있고, 회사 전체 공통 요구사항도 볼수 있어야 합니다. 그래서 일반 직원들을 위해 Position Read-Only Permission Set을 생성해서 아주 제한적으로 Read권한만 부여하는 거죠.
그리고 이 Permission Set을:
Recruiter Group
Hiring Manager Group
Interviewer Group 모두에 포함하면 됩니다.
공통 권한: Review 객체
Recruiter, Hiring Manager, Interviewer전부다 모든 Review객체에 대해 Read, Create, Edit 권한이 필요합니다. 이때, 각 역할별로 Permission Set에 Review 권한을 중복 설정하는 것은 좋지 않은 방법입니다. ❌ Review Object Permission Set을 하나 만들어서 이걸 3개 그룹에 재사용 하는겁니다.
Recruiter Group
Hiring Manager Group
Interviewer Group
최종 설계 그림 (머릿속에 이거 그리면 됨)
역할(페르소나)별로 Permission Set Group 생성하고, 객체별 권한은 Permission Set으로 쪼개기, 그리고 공통 권한은 반드시 재사용하고 “혹시 필요할지도” 권한은 넣지 않도록 합니다. 권한은 최소한으로 부여하고 꼭 필요할때 추가적으로 부여하도록 하는 것이 좋은 설계입니다.
Permission Sets (기능 단위)
Review Object Access
Candidate Object Access
Position Read Only
Job Application Object Access
Hiring Manager Object Access
Permission Set Groups (사람 단위)
Recruiter Group
Hiring Manager Group
Interviewer Group
Create a Permission Set
Review object에 대한 permission set을 만들어 보겠습니다.
Setup > Quick Find > Permission Sets > New
Label: Access and Manage Reviews
License: -None-
Save
저장하고 보여주는 Access and Manage Reviews화면에서 Find Settings검색창에 Reviews를 검색해서
위의 화면에서 Find Settings박스에 Reviews를 검색해서 선택합니다.
Edit버튼을 누릅니다.
Read, Create, 그리고 Edit 권한을 활성화합니다.
Save
사용자에게 Permission Set을 바로 할당할 수 있습니다. 하지만 그 대신 먼저 Permission Set Group을 만들고 이 권한을 그룹에 포함합니다.
Create a Permission Set Group
위에서 설계한대로 3개의 사람기준 Permission Set Group들은 모두 Review객체를 포함합니다. 여기서는 3개의 사람 그룹중 Recruiters를 위한 Permission Set Groups을 생성해보도록 하겠습니다.
Setup > Quick Find > Permission Set Groups > New Permission Set Group
Label: Recruiters
Description: This is the Permission Set Group for Recruiters
Save
현재 페이지에서 Permission Sets in Group링크를 클릭하세요. 다시 들어오시려면, Setup > Quick Find > Permission Set Groups > Recruiters > Permission Sets > Permissions Set in Group
Add Permission Set을 클릭합니다.
위에서 만든 Access and Manage Reviews Permission set을 선택합니다.
Add > Done
Assign Permission Set Group to User
채용 담당자 권한 집합 그룹이 구성되고 검토에 대한 액세스 권한이 부여됩니다. 마지막 단계는 사용자에게 할당하는 것입니다.
Recruiters의 Permission Set Groups페이지에서 다시 들어오시려면, Setup > Quick Find > Permission Set Groups > Recruiters
Manage Assignments버튼을 클릭하세요.
Add Assignment버튼을 클릭하세요.
그룹에 추가하고자 하는 사용자들을 전부 선택한 뒤 Next
특정 기간동안만 권한을 할당하고 싶은 경우에 Specify the expiration date를 선택하고 날짜를 지정합니다.
Assign > Done
그러면 이렇게 Assignments가 만들어 져서 해당 그룹에 액세스 권한을 사용자들에게 부여할 수 있습니다.
Review Access Using Summaries
권한을 여러개 설정하다보면 어떤 Object이 어디서 어떻게 쓰이고 있는지 보고 싶을거잖아요. 그럴때:
Setup > Object Manager > [Object 아무거나] > Object Access에 들어가 보시면 아래와 같이 Permission Sets, Groups, 그리고 Profiles까지 해당 객체에 권한이 할당된 모든 설정들을 한번에 보실 수 있습니다.
그리고 사용자별로 할당된 권한을 보시려면,
Setup > Quick Find > Users를 클릭하고,
사용자를 선택한 뒤,
상단에 View Summary버튼을 클릭하시면 각종 권한과 종속된 Permission Sets를 보실 수 있습니다.
Hands-on Challenge
Create a Permission Set for Access to Positions
For our Recruiting app, create a permission set that grants access to the positions object. Then, add this permission set to the Recruiters permission set group that you created in the unit.
Get help on the challenges for this specific module.
Pre-Work If you haven’t already created the Recruiters permission set group described in this unit, do that now. Otherwise, you won’t be able to complete this challenge.
Create a permission set:
Label: Manage Positions
API Name: Manage_Positions
Add a description (We won’t check for this.)
License: -None-
Enable Positions Object Permissions: Read, Create, and Edit
Add the permission set to the Recruiters permission set group
Verify that the Manage Positions permission set and Recruiters permission set group are displayed in the Object Access Summary for the Position object (We won’t check for this.)
풀이
Positions객체에 접근할 수 있는 Permission Set을 만드세요. 그리고 이 Permission Set을 Recruiters Permission Set Group에 추가하세요.
만약 위의 강좌를 따라오면서 Recruiters Permission Set Group을 안 만드셨으면 지금 얼른 만드세요. 그거 없으면 과제를 완료할 수 없습니다.
그럼 우선 Permission Set을 하나 만들겠습니다.
Setup > Quick Find > Permission Sets > New
Label: Manage Positions
API Name: Manage_Positions
License: -None-
Save
방금 만든 Permission Set에 Position객체를 읽고, 생성하고, 편집할 수 있는 권한을 할당하겠습니다.
아까 Save누르고 보인 Manage Positions화면에서 Object Settings을 클릭하세요 만약 화면을 닫아버리셨다면 Setup > Permission Sets > M > Manage Positions로 다시 들어오셔서 Object Settings를 클릭하세요.
그러면 Object들이 보이실거에요. 그중에 Positions를 찾아서 클릭합니다.
화면에 보이는 Edit버튼을 클릭하세요.
Object Permissions에서 Read, Create, Edit만 체크한 뒤 Save버튼을 누릅니다.
방금 만든 Permission Set을 Recruiters Permission Set Group에 추가할게요.
Setup > Quick Find > Permission Set Groups > Recruiters
이번 강좌에서는 Admin으로서 사용자를 생성하고 관리하는 업무와 비밀번호 정책등을 설정하거나 사용자의 IP나 로그인 시간등을 제한하는 방법에 대해서 알아보도록 하겠습니다.
Create a User
개인에게 권한을 부여하거나 제한하기 위해서는 우선 고객의 정보를 User객체에 입력해야합니다. 사용자 생성은 Admin의 권한이고 Setup에서 이루어 집니다. Setup > Quick Find > Users > New User 또는 Add Multiple Users를 클릭해서 사용자를 등록할 수 있습니다. 해당 페이지에 각종 개인정보를 넣고 Save하시면 User가 등록이 됩니다.
Deactivate a User
Setup에서 User레코드를 Edit하는 페이지에 가보면 Active체크상자가 있는데 그걸 Uncheck 하고 Save하시면 사용자 비활성화가 됩니다. 비활성화된 사용자는 더이상 라이센스를 점유하고 있지 않고 더이상 시스템에 로그인 할수 없어요. 때로 Active할 수 없는 경우가 있는데 그럴때는 User레코드를 Edit으로 들어가지 말고 이름을 눌러서 View하는 페이지로 들어가시면 상단에 Freeze라는 버튼이 보이실거에요. Freeze가 되면 계정은 살아있지만 로그인이 즉시 차단됩니다. 비활성화를 방해하는 요소들을 찾아서 변경한 뒤 비활성화를 하실 수 있습니다.
사용자를 비활성화 할 수 없는 경우:
계층 구조의 핵심: 해당 사용자가 Custom Hierarchy 필드에서 참조되고 있을 때.
워크플로우/프로세스: ‘기본 워크플로우 사용자(Default Workflow User)’로 지정되어 있을 때.
이메일 서비스: 특정 이메일 서비스의 수신자로 설정되어 있을 때.
Set Password Policy
사용자의 비밀번호가 강력하고 안전한지 확인하기 위해 여러 설정을 구성할 수 있습니다.
Password Policies
모든 사용자의 비밀번호가 만료되기까지의 시간과 비밀번호에 필요한 복잡성 수준 지정과 같은 비밀번호 및 로그인 정책을 설정합니다.
Setup > Quick Find > Password Policies에서 비밀번호에 대한 정책을 설정할 수 있습니다.
비밀번호 정책을 사용자별로 설정할 수도 있습니다. 사용자데이타에 비밀번호 정책이 설정되어 있다면 그 정책은 조직의 비번정책보다 우선시됩니다.
User Password Expiration
‘비밀번호가 만료되지 않음’ 권한이 있는 사용자를 제외하고 조직의 모든 사용자에 대한 비밀번호를 만료합니다.
User Password Resets
지정된 사용자의 비밀번호를 재설정합니다.
Login Attempts and Lockout Periods
로그인 시도 실패 횟수가 너무 많아 사용자가 잠긴 경우에 풀어달라고 여러분에게 연락이 올거에요. 아래는 해당 사용자의 액세스를 잠금 해제하는 방법입니다.
조직레벨에서 IP제한하기
Salesforce에 로그인 할수 있는 IP주소를 설정할 수 있습니다. 보통 IP주소는 지역을 기반으로 하기때문에 특정 지역 또는 나라에서만 로그인을 할 수 있도록 믿을 수 있는 IP구간을 설정할 수 있습니다.
Billing Country가 ISO 3166 2자리 코드에 해당하지 않으면 A valid two-letter country code is required.
Hands-on Challenge
Create a Validation Rule
Create a validation rule that displays an error message and prevents users from creating or updating a contact for an account if the contact and account have different zip codes. Allow creating and updating contacts that have no associated account.
Create a validation rule:
Rule Name: Contact_must_be_in_Account_ZIP_Code
Operator: AND (return true if both conditions are true)
Define the two conditions that, combined, will show the error message:
The contact is associated with an account id
The contact mailing zip code is different than the account shipping zip code Hint: Use the API names (MailingPostalCode and Account.ShippingPostalCode) and the <> (Not Equal) operator.
Enter an error message for the validation rule
풀이
연락처와 계정의 우편 번호가 다를 경우, 오류 메시지를 표시하여 사용자가 계정의 연락처를 생성하거나 업데이트할 수 없도록 제한하는 유효성 검사 규칙을 만듭니다. 연결 계정이 없는 연락처에 대해서는 생성 및 업데이트를 허용해야 합니다.
조건을 만드는 생각해야할 기준은 바로 에러메세지를 보여주는 조건입니다. 지금의 경우는 “AccountId가 비어있지 않고, Zip이 다른 경우에 에러메세지를 보여줘라”를 구현해야하는 거에요.
