1

I recently inherited our Salesforce from a more experienced admin with some developer skills...I am a new admin and have zero developer skills. I need to deploy a trigger that the previous admin wrote which is supposedly ready for deployment. It is supposed to create a project record on our custom Project object whenever an opportunity is closed won. Here is the trigger:

trigger CreateProject on Opportunity (after update) {
    List p = new list(); for (Opportunity O: Trigger.New) if(o.stageName == 'Closed Won')
    { 
        SFDC_Project__c SP = new SFDC_Project__c(); 
        sp.name = 'CLIENT-'; sp.total_charge__C = o.est_monthly_recurring_rev_payspan__c;
        sp.total_charge_reimbursement__c = o.est_monthly_recurring_rev_REI__c; sp.project_type__c = 'Implementation';
        sp.Account__c = O.AccountId; sp.sfdc_project_manager__c = '00550000000n0VZ'; 
        sp.opportunity__c = o.id;
        p.add(sp); 
    } 
    insert p; 
}

The trigger has 100% code coverage in our sandbox environment.

Here are the steps I followed to deploy this (since I am new I may have missed something):

1) Opened the developer console in my Sandbox and ran a test on the trigger which succeeded

2) Went to the Sandbox Outbound Change Sets, and created a new Change Set by clicking New, giving it a name, then adding my trigger to it. I uploaded this to Production successfully.

3) Logged into my Production org, went to inbound change sets, and clicked the name of the change set, then clicked Validate...and got the following errors:

Code Coverage Failure

Your organization's code coverage is 59%. You need at least 75% coverage to complete this deployment. Also, the following triggers have 0% code coverage. Each trigger must have at least 1% code coverage.

UpdateOpportunityId

CreateProject

Details: Test coverage of selected Apex Trigger is 0%, at least 1% test coverage is required

TestOpportunityLineItem.TestOpportunityLineItem(), Details: System.DmlException: Insert failed. First exception on row 0; first error: FIELD_CUSTOM_VALIDATION_EXCEPTION, T8 cannot be greater than T9: [T8_Qty__c] Class.TestOpportunityLineItem.TestOpportunityLineItem: line 92, column 1

UpdateOpportunityId, Details: Test coverage of selected Apex Trigger is 0%, at least 1% test coverage is required

Details: Average test coverage across all Apex Classes and Triggers is 59%, at least 75% test coverage is required.

CreateProject is the name of this trigger, but it has 100% code coverage in the Sandbox so I don't understand why it says it has 0% here.

The next line is referring to a validation rule we have on our products, which doesn't allow certain prices to be more than others, but this trigger has nothing to do with opportunity line items...This other trigger does obviously exist, but it's already been successfully deployed and works...that's not the one I'm trying to deploy here.

I would greatly appreciate any help you can provide! Thank you!

  • 1
    I know your are looking for help with this trigger, and the two answers already listed both give you some help with issues in your code. However, you may also want to look at the Process Builder. It should be able to do what you want to do, and without code. – CyberJus Mar 30 '15 at 23:42
  • 1
    WOW! Process Builder is a total game changer for me! I had no idea this existed...It definitely did what I needed, and took ten minutes instead of the massive amount of time the last admin/dev took writing this trigger and the time I've spent troubleshooting it. Thank you so much for mentioning it! – intrkm Mar 31 '15 at 14:17
1

IDs do not carry over from Sandbox to Production. Therefore, it is bad practice to explicitly reference IDs in Apex. In your trigger you have sp.sfdc_project_manager__c = '00550000000n0VZ';.

This is breaking your code.

  • Thanks for your comment. I actually already checked this, as I was also fairly certain IDs were different in the sandbox vs production org, but it is actually referencing the same user in both production and the sandbox. I am not sure why when apparently it isn't supposed to. – intrkm Mar 31 '15 at 12:38
  • That's highly improbable. As in, realistically impossible – Brian Mansfield Mar 31 '15 at 12:41
  • I'd be willing to bet that to verify if they're the same, you're copying the entire URL and pasting it into your browser? Not just replacing the Id parameter, but copying the entire string? – Brian Mansfield Mar 31 '15 at 12:46
  • No. I am copying and pasting the ID to the end of the string. I have it open on my screen right now, two different instances of Salesforce (1 is na3, one is cs2), with the same ID, and the same user showing. I can post a screenshot, just will need to black out the identifying information for the user. – intrkm Mar 31 '15 at 13:00
  • In that case I believe you - if anyone could elaborate on how this is possible, I'd be very interested to hear! I was under the impression salesforce deliberately didn't provide this functionality – Brian Mansfield Mar 31 '15 at 13:03
0

This trigger may not be the issue, but Bri is right about the the Id, Also test coverage is an accumulation of all the test classes in your org.

TestOpportunityLineItem.TestOpportunityLineItem(), Details: System.DmlException: Insert failed. First exception on row 0; first error: FIELD_CUSTOM_VALIDATION_EXCEPTION, T8 cannot be greater than T9: [T8_Qty__c] Class.TestOpportunityLineItem.TestOpportunityLineItem: line 92, column 1

This is breaking because in that test class you are inserting a Oppty and a validation rule is breaking it, I am willing to bet someone put a validation rule inside your production org, but never your dev org;as a result you aren't seeing test class failures.. I don't believe fixing that one test class will bring you up 16%. You should start there though, I believe your prior developer left you in a bad spot.

When users create new validation, workflow rules, or look-up filters you will also need to update the test classes that run on that object (Unless you create custom settings). This is a pain, but what can ya do..

  • Wow, anytime someone creates any of those? I think I might need to lock down our org a bit more. I also need to look into setting something up to notify me when someone does do that, because I'm not sure how I would know otherwise. – intrkm Mar 31 '15 at 13:01
  • Yea it's a pain – EricSSH Mar 31 '15 at 16:19
0

2) Went to the Sandbox Outbound Change Sets, and created a new Change Set by clicking New, giving it a name, then adding my trigger to it. I uploaded this to Production successfully.

It may be odd to mention this but it does not come forth from your question:

You also need to include the test class for your trigger into the change set. Otherwise there are no tests executed for that particular trigger and hence the trigger code coverage will be 0% and also lower your org-wide coverage percentage.

0

For the hard coded ID, this works because the user existed in production and then the sandbox was refreshed. So this is 100% possible when you have access to full or partial sandboxes.

For the code coverage issue, did you deploy the test class?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.