Triggering a workflow on the creation of a 1:N Relationship?_问答_开发者

I am trying to run a workflow on the creation of a 1:n relationship.

I have a Contact entity, and PortalRole entity. When I associate the PortalRole with the contact I would like to trigger a workflow which sends out welcome emails to the users.

The PortalRoles are assigned to the contacts from a ribbon button which launches a HTML web resource and uses JSON / JQuery and the REST services to create the associations.

How can I call the workflow? I need to grab the Contacts emai开发者_如何学Pythonl address and send them 1 of 2 emails depending on how many associations they have (new portal user or portal user gaining extra roles)

You should build your workflow for the PortalRole entity and trigger it from Create. You'll still be able to access Contact fields in the workflow.

The trick is in your last requirement - send "Email A" for the first role association and then "Email B" for the each additional association.

You could add a Yes/No field to Contact called "First Role Assigned." Your workflow would look something like this:

If Contact:FirstRoleAssigned = Yes
- Send "Email B"
Else
- Send "Email A"
- Set Contact:FirstRoleAssigned = Yes

This blog post provides a very good explanation of dealing with relationships.

(So Many) Many-to-Many Options: Which to Use?

So…of these three approaches, which is best? As always, it depends on what you need to do, but here are some rules of thumb you can use as guidance:

Native N:N

Probably the easiest to configure but the most limiting. Use when you only need to know that two records are connected to each other but you don’t need additional information about the connection itself.

Examples:

Custom entity Industry with an N:N to Account Add a custom N:N relationship between the Competitor and Territory entities to track which competitors are active in which territories Custom entity Color with an N:N to Contact (you don’t track your contacts’ favorite colors???)

Manual N:N

A little more work to configure, but generally worth the effort. Use when in addition to knowing two records are connected, you also need information about the connection, such as its status, when it was created and so forth.

Examples:

Associations and Members Events and Registrations (1:N from Contact to Registration, 1:N from Event to Registration) Subscribers and Subscriptions (1:N from Contact to custom entity “Subscription”, 1:N from custom entity “Subscription Product” to Subscription)

Connections and Connection Roles

As I mentioned above, these are actually a specific implementation of the Manual approach. And if you delve into this a little, you’ll find that the Connection entity is a bona-fide customizable entity. You can even customize it, adding custom fields to the connection form and so forth. But…be careful about overdoing it: there’s only one Connection entity, and customizations made for one Connection Role generally will not be applicable to another one.

One specific advantage of these is that a single connection role can connect records of different types (e.g., contacts can refer other contacts, accounts and opportunities)

This is a judgment call, but I’d say to use these when you need to track some information about the actual connections (such as when they’re created and how many there are…), but not that much. Examples:

Referrals (Contact to Contact, Contact to Account, Contact to Opportunity) Former Employee (Contact to Account, Lead to Account) Board of Directors (Contact to custom entity “Board”, Lead to Board)