• Vinay Yelavarthi
  • 0 Points
  • Member since 2016

  • Chatter
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 1
  • 1
For the below question, I was juggling between C & D. Which is  the correct answer?

1) A sales ops user has been identified as the dashboards expert within cloud kicks. This user needs to be able to update dashboard folder access for all non-private folders.
Which permission should the administrator assign to the user?
a)    Create and customize dashboards
b)    Create dashboard folders
c)    Manage reports in public folders
d)    Manage dashboards in public folders

2)    A customer created a case using web to case. They contacted phone support to get an update on the cases two days later. Although the customer is positive that it was created and logged.
What should the administrator reference to troubleshoot the issue?
a)    Contact Email Address
b)    Validation Rules
c)    Assignment Rules
d)    Setup Audit Trail

3)    The sales operations team at Universal Containers purchased a list of shipping companies they would like to be Imported into the Salesforce Org through Import Wizard. Some companies on the list may already have customers.
Which fields should the administrator use to prevent duplicates when importing these Account records?
a)    Owner Name and Account Name
b)    Account Name and Account Site
c)    Account Name and Created Date
d)    Account Name and Billing Address
Today we do not have a release magament process for SFDC releases. I read a lot of articles on the subject but I don't find the best way. There is a lot of tools to do that : Flosum, AutoRABIT, Copado, CloudMax, sfOpticon, Force.com Migration Tool... 
We think to use the Migration tool with SVN and the dataloader to automate all the process and make Continuous Integration with Jenkins. The idea is that we would like to have :
- a sandbox for each developper 
- a sandbox (QA-Integration) to validate the code (SF best practices convention, naming convention,...) 
- a sandbox (UAT) for users tests
- a sandbox (staging) to validate migration to production 
- poduction
What we want to avoid is to take too much time for the prod deployment, found errors in the last step (UAT-staging), found dirty code in another environement than development and we would like to easily roll-back, compare environment, rebase an environment... We think that with the migration tool and svn we can achieve it without encountering too many difficulties but I want to be sure before I implement all the process. So has someone already implemented a similar process in his organization ? Has someone scripts exemple ? If not what do you suggest as a proper process for managing SFDC releases according to our needs ?

Thanks in advance for your answers en your help.