I am going to attend the Admin certification exam this week and wanted to know from someone who attended this exam recently, if there are questions concerning Lightning Vs. Classic edition?
I understood that the questions that are asked are relevant to classic edition only, but I wanted to make sure that this fact is indeed correct and hasn't changed.
Please check following study guide for salesforce adminstrator exam
Some of my colleagues recently appeared for exam and there was no question related to Lightning Vs Classic. And as per above 2 links as well, its not part of administrator exam.
Good luck for exam. :)
I was hoping that someone may be able to help me. The challenge is:
1) My client has an existing Salesforce environment. We would like to replicate it on a new Salesforce Instance.
2) There are some objects and apps that we don't need so is there anyway cloning the Salesforce environment without those?
3) When we clone will we have modify all data access? Or will the cloning repliacte existing profiles?
I understand there is some complexity here, however would greatly appreciate any expert advice.
Many Thanks in advance
There is no easy way to migrate data, since you'll need to add each record in the right order (and update all related records with the IDs of the newly created records they relate to).
In addition, CreatedDate and CreatedBy (audit fields) will be to be switch to 'editable' by Salesforce.
I strongly suggest that it will be safer, more reliable, and faster (more time efficient) to keep the data in the same org, and change the configuration to get the results needed. You can use data jobs within the same org to move data around based on your design decisions, and you can use record types and page layouts to give your users a seemless experience while this is going on in the background.
- Group A needs to create, edit, and delete the Financials object when record type is Submission - Audited Financials
- Group B needs to to create, edit, and delete the Financials object when record type is Submission - Non-audited Financials
- Groups A & B need to create, edit, and delete the Financials object when record type is Moody's Ratings Review
Validations: Group A's profile is set up to have CRE rights for the fields on the Financials object. I've written a validation that will only allow them to edit when the record type is Submission - Audited Financials. I cloned the validation to allow Group B to edit Submission - Non-audited Financials and cloned a third validation that allows Groups A & B to edit Moody's Ratings Review. Still with me?
- This solution gets the job done, but Group A can still create a page for Financials when record type is Submission - Non-audited Financials (aka the only record type they shouldn't create or edit), but when they try to save the record, the validation kicks in and won't allow them to save.
- I don't want to frustate my users, but will use this as a last resort since it's the only thing working properly at the moment.
Permission Sets: I set all the profiles so that every user has read only access to the Financial's fields. I created three permission sets that allowed the groups above to have CRE rights to their specified record type, and assigned my users to each permission set.
- This solution does butt-kiss. If I assign a user to one of the permission sets, they have CRE for every record type. Ideas on where I'm going wrong?
Sharing Settings: so I did even more research and discovered that Sharing Settings should be the path to go ... or so I thought.
- I set up a Public Group with users from Group A. Set up my criteria-based sharing rules for Financials and ... Group A cannot edit Financials for any record type.
Okay Salesforce gurus, can someone please help me figure out what I'm missing, and how to get my users set up to Create and Edit the Financials object by record type? Thanks!
I think you’re very close. It's might be helpful to look at this scenario by separating a few security concepts:
1. Allow read only or read/write access to records based on record type = controlled by OWD and Sharing Rules
2. General ability to perform CRUD operations on records of an object IF sharing rules provide visibiltiy = controlled by Profiles and Permission Sets.
It gets tricky when OWD, sharing and profile settings overlap or appear to conflict with each other.
Record types settings in Profiles - When you restrict a profile so that it includes only a subset of record types for an object, you are really only restricting those users in what record types they can create or which record types they may use when changing the record type of a record they can edit. However, the profile/permission set settings will not restrict a user from viewing additional record types that were created by others.
Permission Sets control basically the same settings as Profiles - Permission sets are basically just a way to add privileges to a more restrictive profile. They control essentially the same privileges as profiles. They are used to selectively “opening up” profile-level settings for sub-sets of users.
Also, remember that if a user's Profile or Permissions Set sets specific record type restrictions for an object, the user can still view all records assigned to any record type for that object as long as the user has visibility to the records via sharing rules.
So, based on what you've shared here, here is an approach that might be helpful:
Sharing Rules Settings
- Set OWD on Financials to Public Read-Only
- Create criteria-based sharing rule to give the Group A Read/Write access to Financials records with record type "Submission - Audited Financials"
- Create criteria-based sharing rule to give Group B Read/Write access to Financials records with record type "Submission - Non-Audited"
- Create criteria-based sharing rule to give Group A and Group B read/write to Financials records with record type "Moody's Ratings Review"
- CRUD: make sure members of Group A and Group B belong to Profiles (and/or to Permissions Sets - see below) that allow read, create, update, delete access to the Financials object, since they will need to be able to edit records they have Read/Write visibility to (based on sharing rules). Make sure all other profiles besides Group A and B have read access to the Financials object.
- Record types: Here, you can limit which type of record types may be created by each profile, or which record types a user may change a record to if they have read/write access to the record (based on sharing rules). But again, this setting does not limit which record types may be viewed or edited.
I don't necessarily see a need for Permission Sets in the scenario described here, but they might apply based on other requirements.
I hope this helps!
Is there any way to filter out the completed modules on trailhead to flush out the new/not completed one?
but has anyone figured out a way to do this?
Please up-vote the idea if it would help you or to help me :)
A third field needs the following to happen. It should equal the Opportunity amount roll up field if the adjusted field is blank. If the adjusted field is not blank then this should be the amount in the field.
This is my formula:
(ISBLANK( Adjusted_MRR__c )),
When the Adjusted_MRR__c is blank my field comes up $ 0.00 instead of the Closed_Won_Opportunity_s__c amount. But When the Adjusted_MRR__C is not blank then this amount shows up.
Why is my Closed_Won_Opportunity_s__c amount not showing up??
Set the wrong IP address on the System Administrator Profile and now all the System Administrators are locked out - any suggestions?
We've opened a case with Salesforce in the hope that they can help, but I thought I'd see if anyone else has made a similar mistake before and, if so, has any suggestions on how to handle it?
Any advice would be very welcome!
I have two custom objects with a master-detail relationship. On the Master record, I have a User Lookup field. I would like to include this person in a workflow email alert being triggered by an action from the child object. Is this possible? Any help is much appreciated. Thank you!
Please do the below
Create a Custom Email field on the Child object
Now create a new field update action on the workflow that you have on the child object and update the custom email field with the email address of the user thats in the lookup field on the master object
the formula will be something like
MasterObject__r.RelatedUser__r. Emailuse the insert field buton to navigate and get the email address
Child Object > Master Object . Related User > Email
Now edit the email alert action and select the email field as the recepient type and select the Custom Email field