Fill lookup on task with ID from 'Related to' Object in Trigger
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
1
down vote
favorite
When a new Task is inserted(before insert) I want to get a lookup field from the object in it's 'whatId'(related to) and assign that to a lookup on the task. This is what I have, I'm pretty sure there is no danger of the 'whatId' being blank so don't worry about that:
List<Id> pmgIds = new List<Id>();
for(SObject temprecord : Trigger.New)
pmgIds.add(temprecord.get('WhatId'));
for(Practice_Management_Guide__c pmg : [SELECT Id,Name,Client__c
FROM Practice_Management_Guide
WHERE Id IN :pmgIds])
for(SObject temprecord:Trigger.New)
if(temprecord.get('WhatId') == pmg.Id)
temprecord.Client__c = pmg.Client__c;
I'm curious is there a better way to do this ? Am I right in saying that you have to query to get other fields from an object related by 'WhatId' ?
apex trigger
add a comment |
up vote
1
down vote
favorite
When a new Task is inserted(before insert) I want to get a lookup field from the object in it's 'whatId'(related to) and assign that to a lookup on the task. This is what I have, I'm pretty sure there is no danger of the 'whatId' being blank so don't worry about that:
List<Id> pmgIds = new List<Id>();
for(SObject temprecord : Trigger.New)
pmgIds.add(temprecord.get('WhatId'));
for(Practice_Management_Guide__c pmg : [SELECT Id,Name,Client__c
FROM Practice_Management_Guide
WHERE Id IN :pmgIds])
for(SObject temprecord:Trigger.New)
if(temprecord.get('WhatId') == pmg.Id)
temprecord.Client__c = pmg.Client__c;
I'm curious is there a better way to do this ? Am I right in saying that you have to query to get other fields from an object related by 'WhatId' ?
apex trigger
1
WhatId can be null, but it would be ignored by the query anyways (it's only interested in values that are actually possible). You're right in presuming that you don't need to check for null in this case.
– sfdcfox
Nov 8 at 21:56
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
When a new Task is inserted(before insert) I want to get a lookup field from the object in it's 'whatId'(related to) and assign that to a lookup on the task. This is what I have, I'm pretty sure there is no danger of the 'whatId' being blank so don't worry about that:
List<Id> pmgIds = new List<Id>();
for(SObject temprecord : Trigger.New)
pmgIds.add(temprecord.get('WhatId'));
for(Practice_Management_Guide__c pmg : [SELECT Id,Name,Client__c
FROM Practice_Management_Guide
WHERE Id IN :pmgIds])
for(SObject temprecord:Trigger.New)
if(temprecord.get('WhatId') == pmg.Id)
temprecord.Client__c = pmg.Client__c;
I'm curious is there a better way to do this ? Am I right in saying that you have to query to get other fields from an object related by 'WhatId' ?
apex trigger
When a new Task is inserted(before insert) I want to get a lookup field from the object in it's 'whatId'(related to) and assign that to a lookup on the task. This is what I have, I'm pretty sure there is no danger of the 'whatId' being blank so don't worry about that:
List<Id> pmgIds = new List<Id>();
for(SObject temprecord : Trigger.New)
pmgIds.add(temprecord.get('WhatId'));
for(Practice_Management_Guide__c pmg : [SELECT Id,Name,Client__c
FROM Practice_Management_Guide
WHERE Id IN :pmgIds])
for(SObject temprecord:Trigger.New)
if(temprecord.get('WhatId') == pmg.Id)
temprecord.Client__c = pmg.Client__c;
I'm curious is there a better way to do this ? Am I right in saying that you have to query to get other fields from an object related by 'WhatId' ?
apex trigger
apex trigger
asked Nov 8 at 21:29
SallyRothroat
338112
338112
1
WhatId can be null, but it would be ignored by the query anyways (it's only interested in values that are actually possible). You're right in presuming that you don't need to check for null in this case.
– sfdcfox
Nov 8 at 21:56
add a comment |
1
WhatId can be null, but it would be ignored by the query anyways (it's only interested in values that are actually possible). You're right in presuming that you don't need to check for null in this case.
– sfdcfox
Nov 8 at 21:56
1
1
WhatId can be null, but it would be ignored by the query anyways (it's only interested in values that are actually possible). You're right in presuming that you don't need to check for null in this case.
– sfdcfox
Nov 8 at 21:56
WhatId can be null, but it would be ignored by the query anyways (it's only interested in values that are actually possible). You're right in presuming that you don't need to check for null in this case.
– sfdcfox
Nov 8 at 21:56
add a comment |
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
Am I right in saying that you have to query to get other fields from an object related by 'WhatId' ?
Yes, you're entirely right. The only exceptions are a handful of core fields (Type
and Name
, off the top of my head) that you can access directly by querying through the What
relationship.
As with any cross-relationship fields, you do have to query to obtain data from another object within your trigger. The trick with WhoId
and WhatId
(and OwnerId
) is that the lookups are polymorphic, so you cannot query from the trigger through the relationship. Instead, you have to accumulate the Ids as you do here and write a separate query against a specific parent object.
I'm curious is there a better way to do this ?
There are some changes you need to make in your code. In particular, this double-loop structure is one of the least efficient ways to search.
Instead, do
Map<Id, Practice_Management_Guide__c> pmgMap = new Map<Id, Practice_Management_Guide__>(
[SELECT Id,Name,Client__c FROM Practice_Management_Guide WHERE Id IN :pmgIds]
);
Then, when you loop back over Trigger.new
, you can just do pmgMap.get(thisTask.WhatId)
.
You don't need to treat Trigger.new
as untyped sObjects. You can assign it to a list of typed objects (List<Task>
) and refer to fields directly on your Tasks rather than using get()
.
That's great thank you
– SallyRothroat
Nov 8 at 21:56
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
Am I right in saying that you have to query to get other fields from an object related by 'WhatId' ?
Yes, you're entirely right. The only exceptions are a handful of core fields (Type
and Name
, off the top of my head) that you can access directly by querying through the What
relationship.
As with any cross-relationship fields, you do have to query to obtain data from another object within your trigger. The trick with WhoId
and WhatId
(and OwnerId
) is that the lookups are polymorphic, so you cannot query from the trigger through the relationship. Instead, you have to accumulate the Ids as you do here and write a separate query against a specific parent object.
I'm curious is there a better way to do this ?
There are some changes you need to make in your code. In particular, this double-loop structure is one of the least efficient ways to search.
Instead, do
Map<Id, Practice_Management_Guide__c> pmgMap = new Map<Id, Practice_Management_Guide__>(
[SELECT Id,Name,Client__c FROM Practice_Management_Guide WHERE Id IN :pmgIds]
);
Then, when you loop back over Trigger.new
, you can just do pmgMap.get(thisTask.WhatId)
.
You don't need to treat Trigger.new
as untyped sObjects. You can assign it to a list of typed objects (List<Task>
) and refer to fields directly on your Tasks rather than using get()
.
That's great thank you
– SallyRothroat
Nov 8 at 21:56
add a comment |
up vote
3
down vote
accepted
Am I right in saying that you have to query to get other fields from an object related by 'WhatId' ?
Yes, you're entirely right. The only exceptions are a handful of core fields (Type
and Name
, off the top of my head) that you can access directly by querying through the What
relationship.
As with any cross-relationship fields, you do have to query to obtain data from another object within your trigger. The trick with WhoId
and WhatId
(and OwnerId
) is that the lookups are polymorphic, so you cannot query from the trigger through the relationship. Instead, you have to accumulate the Ids as you do here and write a separate query against a specific parent object.
I'm curious is there a better way to do this ?
There are some changes you need to make in your code. In particular, this double-loop structure is one of the least efficient ways to search.
Instead, do
Map<Id, Practice_Management_Guide__c> pmgMap = new Map<Id, Practice_Management_Guide__>(
[SELECT Id,Name,Client__c FROM Practice_Management_Guide WHERE Id IN :pmgIds]
);
Then, when you loop back over Trigger.new
, you can just do pmgMap.get(thisTask.WhatId)
.
You don't need to treat Trigger.new
as untyped sObjects. You can assign it to a list of typed objects (List<Task>
) and refer to fields directly on your Tasks rather than using get()
.
That's great thank you
– SallyRothroat
Nov 8 at 21:56
add a comment |
up vote
3
down vote
accepted
up vote
3
down vote
accepted
Am I right in saying that you have to query to get other fields from an object related by 'WhatId' ?
Yes, you're entirely right. The only exceptions are a handful of core fields (Type
and Name
, off the top of my head) that you can access directly by querying through the What
relationship.
As with any cross-relationship fields, you do have to query to obtain data from another object within your trigger. The trick with WhoId
and WhatId
(and OwnerId
) is that the lookups are polymorphic, so you cannot query from the trigger through the relationship. Instead, you have to accumulate the Ids as you do here and write a separate query against a specific parent object.
I'm curious is there a better way to do this ?
There are some changes you need to make in your code. In particular, this double-loop structure is one of the least efficient ways to search.
Instead, do
Map<Id, Practice_Management_Guide__c> pmgMap = new Map<Id, Practice_Management_Guide__>(
[SELECT Id,Name,Client__c FROM Practice_Management_Guide WHERE Id IN :pmgIds]
);
Then, when you loop back over Trigger.new
, you can just do pmgMap.get(thisTask.WhatId)
.
You don't need to treat Trigger.new
as untyped sObjects. You can assign it to a list of typed objects (List<Task>
) and refer to fields directly on your Tasks rather than using get()
.
Am I right in saying that you have to query to get other fields from an object related by 'WhatId' ?
Yes, you're entirely right. The only exceptions are a handful of core fields (Type
and Name
, off the top of my head) that you can access directly by querying through the What
relationship.
As with any cross-relationship fields, you do have to query to obtain data from another object within your trigger. The trick with WhoId
and WhatId
(and OwnerId
) is that the lookups are polymorphic, so you cannot query from the trigger through the relationship. Instead, you have to accumulate the Ids as you do here and write a separate query against a specific parent object.
I'm curious is there a better way to do this ?
There are some changes you need to make in your code. In particular, this double-loop structure is one of the least efficient ways to search.
Instead, do
Map<Id, Practice_Management_Guide__c> pmgMap = new Map<Id, Practice_Management_Guide__>(
[SELECT Id,Name,Client__c FROM Practice_Management_Guide WHERE Id IN :pmgIds]
);
Then, when you loop back over Trigger.new
, you can just do pmgMap.get(thisTask.WhatId)
.
You don't need to treat Trigger.new
as untyped sObjects. You can assign it to a list of typed objects (List<Task>
) and refer to fields directly on your Tasks rather than using get()
.
answered Nov 8 at 21:38
David Reed
26.7k51745
26.7k51745
That's great thank you
– SallyRothroat
Nov 8 at 21:56
add a comment |
That's great thank you
– SallyRothroat
Nov 8 at 21:56
That's great thank you
– SallyRothroat
Nov 8 at 21:56
That's great thank you
– SallyRothroat
Nov 8 at 21:56
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f238802%2ffill-lookup-on-task-with-id-from-related-to-object-in-trigger%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
WhatId can be null, but it would be ignored by the query anyways (it's only interested in values that are actually possible). You're right in presuming that you don't need to check for null in this case.
– sfdcfox
Nov 8 at 21:56