+ Start a Discussion

Total noob trying to create a new trigger and "ENTITY_IS_LOCKED" message

I start by going to the developer console and Choosing "Triggers" within the Setup Entity Type, then below, I choose a Type from the selection list and click the "New" button to the left of the list. After thinking for a few seconds, the platform responds with a window that looks like:





Can not create Apex Trigger on an active organization.





This message is really meaningless to me. Can anyone help decipher it?


Eugene NeimanEugene Neiman

You can't edit a locked object during a workflow processing operation.


You can't create triggers in a live organization directly. It's a protection mechanism against "total noobs" that try and get clever, and end up breaking the system for all their users. Instead, you will need to start with a Developer Edition (DE) for free; join using the link in the upper-right corner of these forums, or by creating a Sandbox (SB), under Setup > Data Management > Sandboxes. Not all organizations have Sandboxes available to them (at least, not without paying for them), so you want a Developer Edition account. Once you have a new DE or SB, you can create the code there, then, once the code is ready, you can move it into your live organization by using one of three methods: 1) for DE accounts, you can create a package (Setup > Create > Packages), upload the package, then install it as a private AppExchange app, 2) for either SB or DE, you can use the Force.com IDE or Ant Toolkit to migrate the code cover, or 3) for SB accounts, you can use an Outbound Change Set (Setup > Deploy > Outbound Change Sets) to upload the changes into your production, and an Inbound Change Set to complete the transfer.



Great - let me give that a try. If things work out, I'll come back and mark this as the solution.


Evidently, this is going to be a lot trickier than I thought. Using the DE environment means that I don't have access to any of the objects already created in our produciton environment, but although we apparently have a sandbox (and maxed out the available usage of 1), I'm unable to login to it.


I guess given the circumstances, it's better for me to work in the sandbox (and hopefully that has access to our custom objects) than totry to work in the DE that has no knowledge of that object, unless I can somehow export from production and move it in the the DE, correct? If so, I need to get access to the sandbox via our admins.


You have to create a sandbox from your production environment.  Setup> Data Management> Sandbox>. It takes a snapshot of your production instance. You perform all apex development within that. You have to have code coverage of any apex code before you can deploy it to your production instance.


You can refresh the sandbox, assuming you have permission. This will reset the password to your current password. You should check with your admins even if you have permission to make sure you won't be messing anything up. Sandbox use would be ideal, since Change Sets are easier to use than packages (relatively).


You can copy your production to a DE by using the Force.com IDE, or, if you prefer, you can "package" (Setup > Create > Packages) the necessary setup items, upload it, and install it in the IDE. From there, you can create the code you want, then package it back up and reinstall it back in production.

" It's a protection mechanism against "total noobs" that try and get clever"

Lol - That's awesome. I am only a few steps past this point.

OK - making good progress - code is working in SB environment so it looks like the only remaining step is to move it into production environment. I managed to create the change set to include only the trigger that I had developed. But when trying to upload, it gave me the error message:


[red stop sign] This organization isn't authorized to upload change sets to other organizations. For authorization, contact the deployment connections administrators on the organizations where you want to upload changes.


I feel like I am just inches (centimetres?) away from achieving my goal.


In your production account, you have to authorize the connection from your sandbox. Setup > Deploy > Deployment Connections.


For some reason, I thought I had replied to this suggestion but apparently not. In any case, when I set up the sandbox, automatically a *One-Way* conneciton was created, but I didn't realize that I had to also enable the other direction. This has been done now, although now I am running into code coverage issues. The most puzzling aspect is that when my test class runs the trigger code, it gives an error in the test class, while working correctly in the normal UI of the sandbox. Specifically, the error I receive is:




System.DmlException: Insert failed. First exception on row 0; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, PostToChatterOnNewTechRoadmap: execution of AfterInsert

caused by: System.QueryException: List has no rows for assignment to SObject

Trigger.PostToChatterOnNewTechRoadmap: line 12, column 1: []




Line 12 in the trigger is simply:


CollaborationGroup chatterGroup = [SELECT Id FROM CollaborationGroup WHERE Name='Technology Roadmap' LIMIT 1];


which performs the intended action when I create a new "Technology Roadmap" object in the table, or even when I execute the select statements in the Query Editor.


So what gives???


Thanks in advance for your help.


It seems like others have the same issue and under similar circumstances as mine - a trigger that tries to get a reference to a CollaborationGroup object using a query:




I'm not sure the linked question above was resolved, but how can we properly test the code if the methods don't work in an automated test class even though they work in regular user testing? I can actually force the error to go away by hardcoding the Id of the CollborationGroup like so:


//CollaborationGroup chatterGroup = [SELECT Id FROM CollaborationGroup WHERE Name=:'Technology Roadmap' LIMIT 1];
//The above line causes an error while running this code in automated testing ONLY, so we have no alternative but to hardcode
CollaborationGroup chatterGroup = new CollaborationGroup();
chatterGroup.id = '0F9W0000000Cch3KAC';

The problem is that the hard-coded ID will not match the ID of the same group in production - the whole reason I was using a query. So to get around both the testing requirements AND actually making the code work in real life, I have to do silly things like (the code below worked, by the way, in both automated and user  testing):


    CollaborationGroup chatterGroup;
	List<CollaborationGroup> chatterGroups = [SELECT Id FROM CollaborationGroup WHERE Name=:'Technology Roadmap' LIMIT 1];
    if (chatterGroups.isEmpty()) {
    	chatterGroup = new CollaborationGroup();
    	chatterGroup.id = '0F9W0000000Cch3KAC';
    } else {
        chatterGroup = chatterGroups[0];


Or is there a better way?


In any case, my code coverage did not update - presumably it is still at zero despite having passed the automated testing.