Lookup action

[jhorbulyk]

New Lookup action should be created for the Salesforce component. This action should:

• [ ] Have a first dynamically populated drop down select where customer can select an object type she would like to lookup, e.g. Account. Types in the dropdown should be dynamically fetched via Salesforce REST Metadata API,
• [ ] Have a second dynamically populated drop down select that is dependent on the first one. In this select customer can select a field that is presented both with full name and internal name (e.g. External ID (extID__c)) (see example below on which fields should be presented to the user)
• [ ] Have a single string inbound metadata that should be filled with the value using expression that would be compared with the value of the field above.

Which fields should be used for lookup?

Salesforce have a flexible field structure here is the sample metadata description of the Contact object (has a parent relation to Account):

{
  "fullName": "Contact",
  "actionOverrides": [],
  "compactLayoutAssignment": "SYSTEM",
  "enableFeeds": "true",
  "enableHistory": "false",
  "fields": [
    {
      "fullName": "AccountId",
      "trackFeedHistory": "true",
      "type": "Lookup"
    },
    {
      "fullName": "AssistantName",
      "trackFeedHistory": "false"
    },
    {
      "fullName": "OwnerId",
      "trackFeedHistory": "true",
      "type": "Lookup"
    },
    {
      "fullName": "Phone",
      "trackFeedHistory": "false"
    },
    {
      "fullName": "extID__c",
      "caseSensitive": "true",
      "description": "External ID",
      "externalId": "true",
      "label": "extID",
      "length": "255",
      "required": "false",
      "trackFeedHistory": "false",
      "type": "Text",
      "unique": "true"
    }
  ],
  "label": "Contact",
  "listViews": {
  },
  "searchLayouts": {},
  "sharingModel": "ControlledByParent"
}

Full JSON you can find here

Based on the information above list of fields available for lookup should include:

• [ ] All fields of type Lookup
• [ ] All fields where externalId=true
• [ ] All fields where unique=true

Please note that external ID fields are not necessarily unique:

So for Contact based on example above we should see following fields:

• AccountId
• OwnerId
• ReportsToId
• External ID

How results should be handled

It is essential to agree on the proper result handling, for lookup action we may have multiple outcomes:

1. Lookup failed - we were not able to find any parent object. In this case Lookup action should emit a single message with empty body.
2. Lookup found a single object, e.g. we were able to identify an parent Account to the Contact - in this case a single message will be emitted, found object will be a body of the message
3. Lookup found multiple objects (that may happen when lookup is made by non-unique field) - each found object will be emitted with the separate message

See more information about relationships between Salesforce objects here.

[jhorbulyk]

This action is possible through the SOQL Query Action but there is an ask from customers for this functionality to be exposed in a way that does not require learning the SOQL language.

One way this functionality could work is that:

1. A customer is presented with a dropdown to select an object type.
2. Once a customer selects an object type, the customer is presented with a dropdown to select a unique field/property on the object. (Potentially uniqueness constraints may also exist on combinations of fields/properties.)
3. Once a customer selects a field/property, they are presented an input (or inputs) to enter value(s) to lookup.
4. When executed, the component fetches the single (or potentially non-existant) object with the provided value.

[zubairov]

Questions:

• Why limiting this action to a lookup based only on unique fields?
• Why limiting this action to do a lookup on the strong equality, how about substrings (e.g. name like '%foo%')?
• What if we need to lookup based on parent object values (e.g. Contact with that particular ID and belonging to Account with name Acme)

[jhorbulyk]

Why limiting this action to a lookup based only on unique fields?

What would you expect to happen if this action matched more than one value? Emit both? Throw an exception? Either may be useful in some scenarios. Can you give me an example of such a scenario where one of the two behaviors would be useful?

Why limiting this action to do a lookup on the strong equality, how about substrings (e.g. name like '%foo%')?

If we assume that we are in a situation where we want to match exactly one record, how could we assure that we only produce one record? For situations where multiple records are matched, see the questions on the above point?

What if we need to lookup based on parent object values (e.g. Contact with that particular ID and belonging to Account with name Acme)

I don't know. Does salesforce allow you to create uniqueness constraints than span objects?

[yuvallavi2]

I send you guys an email regarding "Referencing Objects by IDs" in Salesforce

[stas-fomenko]

CDoD

Development:

• [x] Code is written and formatted in accordance with the Styling guide.
• [x] Component logs does not contain any sensitive data (credentials, input/output requests, Environment variables)
• [ ] Code is covered with unit tests.
• [x] Triggers/actions comply with OIH patterns.
• [x] Documentation (README.md file in the Github) is 100% ready.
• [x] Component code is covered with integration tests.
• [x] Component code is reviewed and fixed, if needed.

QA:

• [x] Test cases for the component are ready at the TestRail.
• [ ] Functional testing is finished.
• [ ] Regression testing is finished (optional).
• [ ] All the development branches are reviewed and merged into master
• [ ] Component is deployed to the production stage (app.elastic.io).
  • Smoke test is finished there.
  • Component has a proper access level
• [ ] Release notes are done. (+ changelogs in GH repo)
• [ ] Component Roadmap is updated.