Webform CiviCRM or CiviCRM Entity?

Question

Until now whenever I've needed to enable site visitors to enter or update data in Civi on Drupal sites I've used webforms and the excellent Webform CiviCRM integration module. By and large it does the trick. However on a couple of sites I'm currently working on I need to enable suitably authorised users to create some content - I'll call it a project profile - that will contain a mixture of Civi data (org name, related individual contact name/s, website, etc.) and what would sensibly be Drupal field data (a couple of URLs, some images, a logo, maybe a link to a Youtube video, some descriptive text, etc.). I've read all the stuff I can find about the CiviCRM Entity module and it sounds like the right fit for my needs.

If the content creator would only ever create one project profile then a webform based approach seems optimal, but I can see that users may want to create multiple project profiles, and have the ability to edit them, which for me seems to indicate that CiviCRM Entity is the way to go.

So I've started to play with it, and now I'm less certain. I've created a new Drupal content type (project profile), and want to include an organisation name that will be stored in CiviCRM. Using this post as a guide to how to go about it I've got the field to work pretty much as I need it, but this seems like a lot of work to get just one field in my content type to do what I want. Repeating this for each field that I want to be included that contains data from Civi entities will take some time, and I'm unclear as to how the disparate bits of data will be linked together - if the author enters an organisation name in one field and an email address in another does the module understand that the email address belongs to the organisation record?

Which all makes me wonder that maybe I'm going about it the wrong way.

Should I instead be adding Drupal fields to the CiviCRM Contact entity and using the CiviCRM Entity Reference module to bring in data from other CiviCRM entities (phone number, email address, etc.)? Or is that approach essentially the same?

I'm concerned about investing a huge amount of time going down the CiviCRM Entity route only to find that it's not the best approach for my use case, but I'm not even clear about what the key questions are that might help me make a good decision.

This looks like a really powerful approach, but it also feels like I'm highly likely to not get the result that I want, and spend a lot of time getting there.

Any advice, links to good guides, videos etc., most welcome.

Answer 1

CiviCRM Entity is the way to go if you want content creators to reference create CiviCRM data on nodes or other Drupal entity types... The downside is, assembly on some not so well documented features required. We have used it to allow users to add/edit contacts with emails etc. Well as you know, I wrote that article.

There is this article too which tries to explain the CiviCRM Entity Reference field: https://skvare.com/blog/using-civicrm-entity-reference-field-submodule-inline-entity-form

If you place a CiviCRM Entity Reference field on the Contact entity, and target Emails, then it will save the email and connect it to the contact as you would expect them to be. CiviCRM Entity Reference field is a "remote" reference field, in that it doesn't save data in any Drupal field tables, but accesses the Civi data directly.

You shouldn't have to setup your forms and any CiviCRM Entity Reference fields but once, and then you can use the same config with Entityreference fields on your node type over and over.

One big disadvantage to the D7 version is that you cannot have multiple "form modes" in D7. That is multiple configurations of which fields appear on edit forms. So if you want one entityreference field inline entity form for an organization contact, and another for an individual contact, you can run into problems, because you want the organization name for the org contact, and maybe first / last name for the individual contact.

You can use hook_form_alter or CSS to hide fields when needed though too. You would configure your contact edit form to have all the properties/fields you may need, and then hide them as necessary for the different reference fields. That will require some development and special knowledge.

CiviCRM Entity is a very powerful tool, but does require some learning and elbow grease, and sometimes code, to make very custom setups.

As to which tool to use when, that depends on the use case IMO. I'd be happy to chat about it sometime on CiviCRM mattermost, chat.civicrm.org, civicrm entity channel, just ping jackrabbithanna. We use Webform CiviCRM a lot too.