Answers.Body: <p>Install the redirect module and make the contribution page URL redirect to the webform.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-20T16:07:50.783Z
Answers.Text: There are often multiple webforms related to a single contribution page..
Answers.UserDisplayName: commonpike
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-10T06:18:52.183Z
Answers.LastActivityDate: 2017-03-10T06:18:52.183Z
Answers.UserDisplayName: Yossi
Answers.Body: <p>If your main issue is hiding the CiviCRM contibution page you could adapt the Drupal permissions (e.g. "make online contributions") in a way that visitors are not allowed to see or use them.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-10T07:27:45.807Z
Answers.LastActivityDate: 2017-03-10T07:27:45.807Z
Answers.UserDisplayName: Fabian
Answers.Body: <p>Just reading this</p>
  
  <p><a href="https://wiki.civicrm.org/confluence/display/CRMDOC/Webform+CiviCRM+Integration#WebformCiviCRMIntegration-Acceptingpaymentsthroughawebform" rel="nofollow noreferrer">https://wiki.civicrm.org/confluence/display/CRMDOC/Webform+CiviCRM+Integration#WebformCiviCRMIntegration-Acceptingpaymentsthroughawebform</a></p>
  
  <blockquote>
    <p>When creating a contribution, event or membership webform that
    includes payments, first set up a dedicated contribution page for the
    sole purpose of embedding it on one or more webforms. Most of the
    contribution page settings will be ignored by the webform. Only the
    following need to be configured: </p>
    
    <ul>
    <li>Title: This will be displayed on the webform </li>
    <li>Financial type  </li>
    <li>Currency</li>
    <li>Payment processor </li>
    <li>Email receipt - if enabled, these will be sent from
    the webform just as they would be from the real contribution page</li>
    </ul>
  </blockquote>
  
  <p>So that seems to suggest to create a few generic contribution pages (membership,event registration,purchase), ignore the payments amounts, 'disable access' for those (using the suggestions from other answers here), and go wild on the webforms.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-20T21:06:55.840Z
Answers.Text: so it does not need setting to be a public form
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-20T16:07:10.583Z
Answers.LastActivityDate: 2017-03-20T16:07:10.583Z
Answers.UserDisplayName: commonpike
Body: <p>On a clients site, we are using several contribution pages, and some of them are duplicated in webforms. I have a hard time deciding when to use what. I prefer the webforms, but I always end up configuring everything twice. What is the <em>intended</em> workflow ?</p>
  
  <p>For a contribution, a contribution page is needed. But for a dozen similar contributions, I can use webforms pointing to the same contribution page, and configure the payment amounts there. However, since I can't 'hide' the civicrm page from the web, I do need to configure the amounts there, too. I always end up puzzling on how to sync these amounts from the contribution page to the webpage (pricesets - matrix - confusion).</p>
  
  <p>On contribution pages, I can include 'profiles' to get additional information. On the webforms, I can just include the wanted fields from the contacts. since I can't 'hide' the civicrm page from the web, I would have to do both.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-03-09T16:32:22.243Z
Comments.Text: Tips on best practices are welcome, but they are not answers (otherwise, rogue mods will come along and ban this question for being subjective). The question is - what is the *intended* workflow here.
Comments.UserDisplayName: commonpike
Tags: <civicontribute><webform-civicrm><workflow>
Title: Webforms vs Contribution pages - workflow
ThreadText: # Webforms vs Contribution pages - workflow
  
  (Asked by: username_0 on 2017-03-09)
  
  On a clients site, we are using several contribution pages, and some of them are duplicated in webforms. I have a hard time deciding when to use what. I prefer the webforms, but I always end up configuring everything twice. What is the *intended* workflow ?
  
  For a contribution, a contribution page is needed. But for a dozen similar contributions, I can use webforms pointing to the same contribution page, and configure the payment amounts there. However, since I can't 'hide' the civicrm page from the web, I do need to configure the amounts there, too. I always end up puzzling on how to sync these amounts from the contribution page to the webpage (pricesets - matrix - confusion).
  
  On contribution pages, I can include 'profiles' to get additional information. On the webforms, I can just include the wanted fields from the contacts. since I can't 'hide' the civicrm page from the web, I would have to do both.
  
  **Tags:** civicontribute, webform-civicrm, workflow
  
  > **Comments:**
  > **username_0**: Tips on best practices are welcome, but they are not answers (otherwise, rogue mods will come along and ban this question for being subjective). The question is - what is the *intended* workflow here.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2017-03-10. Score: 1
  
  Install the redirect module and make the contribution page URL redirect to the webform.
  
  > **Comments:**
  > **username_0**: There are often multiple webforms related to a single contribution page..  
  
  ---
  
  ### Answer by username_2 on 2017-03-10. Score: 1
  
  If your main issue is hiding the CiviCRM contibution page you could adapt the Drupal permissions (e.g. "make online contributions") in a way that visitors are not allowed to see or use them.
  
  
  ---
  
  ### Answer by username_0 on 2017-03-20. Score: 0
  
  Just reading this
  
  <https://wiki.civicrm.org/confluence/display/CRMDOC/Webform+CiviCRM+Integration#WebformCiviCRMIntegration-Acceptingpaymentsthroughawebform>
  
  > When creating a contribution, event or membership webform that
  > includes payments, first set up a dedicated contribution page for the
  > sole purpose of embedding it on one or more webforms. Most of the
  > contribution page settings will be ignored by the webform. Only the
  > following need to be configured:
  >
  > * Title: This will be displayed on the webform
  > * Financial type
  > * Currency
  > * Payment processor
  > * Email receipt - if enabled, these will be sent from
  >   the webform just as they would be from the real contribution page
  
  So that seems to suggest to create a few generic contribution pages (membership,event registration,purchase), ignore the payments amounts, 'disable access' for those (using the suggestions from other answers here), and go wild on the webforms.
  
  > **Comments:**
  > **username_3**: so it does not need setting to be a public form  
  
  ---
  
  