SharePoint List Forms Extensions feature - introduction
•Transferir como PPTX, PDF•
2 gostaram•2,236 visualizações
Would you like to have advanced, dynamic forms by simply using the out-of-the-box SharePoint list forms? With KWizCom's List Forms Extensions Feature you can do it, without any need for InfoPath skills, and without having to purchase expensive SharePoint Enterprise license. This presentation includes a very detailed demo walkthrough that really shows you how this product works, and how you can easily create advanced from-based solutions in SharePoint without any development. For more details about the product, please visit the product page: http://www.kwizcom.com/sharepoint-add-ons/sharepoint-mobile-extensions/overview/
Recomendados
Recomendados
Mais conteúdo relacionado
Mais de Nimrod Geva
Mais de Nimrod Geva (12)
Último
Último (20)
SharePoint List Forms Extensions feature - introduction
- 1. SharePoint List Forms Extensions Feature Wipe out SharePoint List forms limitations, Real Dynamic Forms – for Everyone!
- 2. KWizCom Corporation • Founded in 2005 • Headquartered in Toronto • Global vendor of SharePoint Add-Ons • 5000+ customers worldwide
- 3. Over 40 different addons, solving various SharePoint challenges! http://www.kwizcom.com/sharepoint-add-ons/
- 4. Forms in SharePoint 2010/2013 What are my options
- 5. Implementing forms in SharePoint SharePoint List forms Immediate & simple Works in all SharePoint editions LIMITED End-user tool Forms Server & InfoPath Advanced, dynamic forms Requires SharePoint Enterprise license Requires technical InfoPath skills Power-user tool
- 6. SharePoint List Forms – the fastest option! Immediate & easy implementation Support for various field types Fully integrated with workflow, alerts and search
- 7. What’s missing? Form = “A Bunch of fields” There’s no context Always same actions (menus)
- 8. What’s missing in SharePoint forms? Field-level permissions View-level permissions Dynamic field constraints Dynamic default values Field-grouping (Tabs) Dynamic Custom Menus Cascaded fields Repeating rows fields
- 9. SharePoint List Forms Extensions Turn your SharePoint list forms into Smart, Context-Sensitive Forms
- 10. SharePoint List Forms Extensions Get all advanced form features End-user tool, no technical skills required No need for expensive SharePoint Enterprise license! Implement dynamic forms Faster!
- 11. Product Features Let’s show you the features by implementing an IT Helpdesk solution, step-by-step Helpdesk engineer Customer
- 12. Demo Static Field permissions: Allowing different users access different fields
- 13. This is the Support Request form Some fields should be visible to customers Customer Helpdesk Engineer Other fields should be visible to Helpdesk engineers
- 14. 1 Hide marked fields from everyone 2 Show these fields only to Helpdesk engineers Helpdesk Engineer
- 15. Let’s configure List Forms Extensions to hide these fields
- 16. 1
- 17. 1 2
- 18. 1 Select fields that you wish to show/hide/disable
- 20. Type users/groups for which this permission rule should apply 3
- 21. Select the list forms where you want to apply the field permission rule 4
- 22. In run-time, these rules are processed one by one according to their order. Click to add static permission rules 5
- 23. Let’s save the settings and see which fields users see now when creating a new Support Request.
- 24. Customer In New/Edit forms users see only these fields, as configured
- 25. Customer In View form users see all fields, as configured
- 26. Helpdesk Engineer Now let’s make these fields visible to Helpdesk engineers
- 27. Select fields that you wish to show 1 Select “Show” permission type 2 3 Type users/groups for which this permission rule should apply Click to add static permission rules 4
- 28. New rules added, showing the selected fields to Helpdesk engineers. 5
- 29. Customer Customers still see only part of the fields, as configured
- 30. While Helpdesk engineers see all fields, as configured. Helpdesk Engineer
- 31. Demo Dynamic field permissions: Dynamically hiding/disabling fields according to logical criteria
- 32. Customer Selecting a category should show and hide the relevant fields
- 35. Let’s configure List Forms Extensions to dynamically show these fields
- 36. 1
- 37. 1 2
- 38. 1 Hide the “Hardware type” field, and add rule 2 3
- 39. 1 Show the “Hardware type” field if Category=“Hardware” 2 3 4
- 40. These 2 rules make the “Hardware type” become visible only when Category field equals “Hardware”
- 41. These 2 rules make the “Hardware type” become visible only when Category field equals “Hardware” Let’s click “OK” to save settings
- 42. Customer
- 43. Customer
- 44. Customer
- 45. Customer
- 46. These 2 fields should be displayed only when Issue status field equals “Closed” Helpdesk Engineer
- 47. Let’s configure List Forms Extensions to dynamically show these fields
- 48. 1
- 49. 1 2
- 50. These 2 dynamic rules display the Issue closing date and Resolution fields only if Issue status equals “Closed” Let’s click “OK” to save settings
- 52. Let’s close this Support Request.. Helpdesk Engineer
- 53. Relevant fields appear when Issue status is “Closed” Helpdesk Engineer
- 54. Demo Dynamic default values: 1. Different default values for different people 2. Automatically update document Title to be equal to the file’s name
- 55. Demo Different default values for different people
- 56. Customer For a customer, “Employee” field’s default value should be equal to [Me] (Although it’s invisible)
- 57. For Helpdesk engineers, The “Employee” field’s default value should be empty Helpdesk Engineer
- 58. Let’s configure the “Employee” field’s default value to be equal to [Me] only for customers.
- 59. 1
- 60. 2
- 61. We have configured 2 Default value rules
- 62. 1st Helpdesk Engineer rule: set the default value to [Me] for everyone Customer 2nd rule: set the “Employee” field’s default value to be empty only for Helpdesk engineers
- 63. Demo Automatically update a document’s Title (This has nothing to do with our Helpdesk example, but still it’s an annoying issue…)
- 65. Then click the “List Extensions Settings” menu
- 66. Select the field for which you want to setup a default value
- 67. Define your dynamic default value And click to add this rule
- 68. Rule added
- 69. Click “OK” to save the settings
- 70. Let’s add now a new document
- 73. Demo Field Constraints: 1. Dynamic: Conditionally-mandatory fields 2. Custom: Validate custom pattern using regular expressions
- 75. These 2 fields should be mandatory only when Issue status field equals “Closed” Helpdesk Engineer
- 76. Let’s configure the Resolution and Issue closing date fields to be mandatory only if Issue status equals “Closed”.
- 77. 1
- 78. 2
- 79. Select the field that you wish to validate Define the validation rule 1 Define conditions (when to validate the field’s value) 2 3 4 Click to add this field validation rule
- 80. We’ve configured 3 field validation rules
- 81. Issue closing date mandatory and not in the future Resolution mandatory
- 82. Helpdesk engineer edits a Support Request item Helpdesk Engineer
- 83. Change Issue status to “Closed” Helpdesk Engineer
- 84. Try to save without updating Resolution and Issue closing date fields Helpdesk Engineer
- 86. Demo Field Grouping: Lets divide a long form to multiple tabs, each visible to relevant audience
- 87. 1 2
- 88. 1 Decide which fields appear in each groups Create field groups 2 3 Define who can see this field-group 4 Configure group layout settings
- 89. This is the group (tab) used to create support requests Customer
- 90. And this one is for Helpdesk engineers to update case resolution details. Helpdesk engineer
- 91. Customer sees only one tab, because he has no permissions to see any of the fields in the other tab. Customer
- 92. Helpdesk Engineer Helpdesk engineer sees the 2 tabs
- 94. Summary – List Forms Extensions Field-level permissions View-level permissions Dynamic field constraints Dynamic default values Field-grouping (Tabs) List Forms Extensions
- 95. Field-level permissions View-level permissions Dynamic field constraints Dynamic default values Field-grouping (Tabs) Dynamic Custom Menus Cascaded fields Repeating rows field List Forms Extensions List Custom Actions Cascading Lookup Plus Repeating Rows Field Forms Bundle KWizCom’s Forms Bundle
- 96. SharePoint List Forms Extensions Training Resources • Product web page: http://www.kwizcom.com/sharepoint-add-ons/sharepoint-list-formsextensions-feature/overview/ • FREE 30-day evaluation version (SP2007, 2010, 2013): http://www.kwizcom.com/sharepoint-add-ons/sharepoint-list-formsextensions-feature/download/ • Admin guide: http://www.kwizcom.com/objects/ListFormsExtensions/v12.3.00/KWizCom _SharePoint_List_Forms_Extensions_Feature_Admin_Guide.pdf • Training videos: http://www.kwizcom.com/sharepoint-add-ons/sharepoint-list-formsextensions-feature/training-videos/ 96
- 97. Thank you! Nimrod Geva Product Group Manager, KWizCom nimrod@kwizcom.com
Notas do Editor
- The problem is there is no logical connection between the fields. You can easily for example define a task where its Due Date is earlier than its Start Date – this woul pass SharePoint validation, but obviously it is not logical.
- Here we have a support request form.The form has some fields that should be visible and updatable by end users (customer), and some – by Helpdesk engineers..
- Let’s hide the marked fields from everyone, and then show them only to the Helpdesk engineers group
- By clicking the “Add field-level permission rule” we have added 4 rules for the 4 selected fields.These rules are processed in run-time when a user opens any of the list forms.These rules are called “Static rules” because we did not use any conditions, we skipped over the “Conditions” sections.Last thing to do is click “Apply” to save the settings.Let’s see the results…
- Users cannot see those fields that we have hidden in New/Edit forms (Including administrator).
- In the View form these fields are visible (as configured).
- Now, let’s enable ONLY helpdesk engineers to view and update these fields.
- Let’s click “Apply” to save the settings and see the results…
- As a customer I still see the same fields, and do not see the fields that were configured as hidden
- As a helpdesk engineer I can see all fields, as configured
- So, we saw how we can hide fields from specific user/group. We call it ”Static” field permissions because these permission rules apply always, depending only on who you are (Customer or Helpdesk engineer in our example).In this demo we’ll see “Dynamic” field permissions; these are permission rules that can be conditionally applied, depending on the current situation (and not only on who is the current user).
- When reporting an issue, the end-user has to select the issue category. Depending on the selected value, different fields should appear, which are relevant to the selected category.
- If user selects the “Hardware” category…
- If user selects the “Software” category…
- 2 rules were added:First one hides the “Hardware type” field always, from everyone and the second rule shows the field only if Category field equals “Hardware”.Let’s repeat the same way and configure “Which software?” field be visible only when Category field equals “Software”
- Let’s save the settings and check the results…
- As a result, a new “Hardware type” choice fields appears.
- And if I choose the “Software” category, the relevant field appears.
- The Resolution and Issue closing date also need to be displayed in a dynamic way: only if Issue status field equals “Closed”.Let’s configure the appropriate dynamic permission rules.
- Let’s save the settings and check the results…
- When a customer creates a new Support Request item, he cannot change the Employee field because we made it invisible for him.We would like that field to have the value of the current customer ([Me]) in this case.
- For a Helpdesk engineer, the “Employee” field is configured to be visible so he’ll be able to create support requests on behalf of customers. In this case we prefer to leave the “Employee” field’s default value empty.
- So this is our out-of-the-box documents library.Let’s configure its default values settings…
- Let’s select the “Field default values” option, under the “List Extensions Settings” menu. This will redirect us to the Default values settings page:
- Remember these 2 fields (Resolution and Issue closing date)?We’ve already configured them to appear to Helpdesk engineers only when Issue status field is set to “Closed”.Now, we want these fields to be mandatory, only if Issue status equals “Closed”. So, what we want is these fields to be conditionally-mandatory. This is a dynamic constraint.
- So, we’ve configured 3 field validation rules:
- So, we’ve configured 3 field validation rules:According to rules 1 and 2, Issue closing date field is mandatory and also cannot be a future date (later than today) if Issue status equals “Closed”.According to rule 3, Resolution field is mandatory if Issue status equals “Closed”.Let’s see how this works…