The Service Request sub-group allows the administrator to define behaviors for service requests within your core. The settings are separated into two groups, Basic and Advanced. Please contact iLab support‍ to access the 'Advanced' setting options.

• Basic
• Advanced

Basic

Basic settings can be defined by core administrators and do not require iLab intervention. 

• Override Request Services tab name: You may name your Request Services tab anything you would like. In the example below, we have changed the name to "Core Requests".

• Allow service requests to be backdated: Allows service requests to be backdated. If this field is defined as YES, cores and users can backdate when they create a request prior to submitting the request to the core. Core administrators can also backdate under the edit pencil of the Managing a Single Service Request‍ on the far right of a request.
• Allow charges on service requests to be backdated:  Line item charges may be backdated on a service request. If this field is defined as YES, the following option will display for all charges within the request.

• Allow past pricing to be applied to charges: Define this field as YES if you would like to allow users apply past pricing structures to current charges.
• Rename the Service ID/Request name label on new service requests: You may re-name the Service ID field, if you wish. In the example below, we have named it "Test Name and Label".
• Custom reportable field name: You may add your own field to your core's service request. This field is then a data point, and can be used and viewed in your core's reports. In the example below, we have created a new custom field name called "miscellaneous". This will show as a free text field.

• Custom reportable field required?: Indicate whether the custom reportable field (in the example case, "Miscellaneous") will be required for all service requests. If yes, the field cannot be blank. A red star beside the field indicates if it is required.

• Custom fields spec: This is a second custom reportable field (in conjunction with "Miscellaneous") that will populate as a dropdown. Please contact iLab support for the proper format to enter if you would like to use this field. 
• Display custom reportable field on service request list view: Indicate whether your custom field should be viewable on the request list view. If defined as YES, the field will display as shown below.

• Show service request project section?: Define this field as YES if you would like to display the service request projects (top half of the request services tab) your facility offers.

• Show service projects section to the customer?: Define this as YES if you would like your customers to see the service projects you offer in the core.
• Service Projects Section Header: You may define what you would like to call your project section. In our example, it has been named "Service Projects and Quote Requests".

• Service Project Section description: Enter a description of what your Service Project Section is. This will display to your customers. In our example, we have included the description, "You may enter a description here".
• Service project section open by default: Indicate whether the service project section should open automatically when a user clicks the Request Services tab.
• Show service project templates grouped by category?: Service project templates can be grouped by category. The category can be set within the edit interface of the service project template (Editing the Service Requests panel‍).
• Hide service list all together?: You may select to hide the list of services (bottom half on your Request Services tab) from everyone by defining this field as YES. Typically this will only be used by equipment cores without add on charges.
• Hide service list from the customer?: You may select to hide the list of services on your Request Services tab from customers only by defining this field as YES.
• Service list open by default?: You may select to open the service list every time a user opens the Request Services tab by defining this field as YES. Services automatically default to being closed and listed by category.
• Service list description: Enter a overall description of your services. This will be viewable to anyone who views the Request Services tab for your core.
• Display services organized by category:  You may define how your services are grouped by default. In our example, we have defined this field as YES, therefore the services are grouped by category. Note that you may always change this within the application by clicking on the "alphabetically" link to link your templates alphabetically instead.

• Minimize the service description: Define this field as YES if you would like to minimize the resource description by default. Customers may then expand the resource to see more, if they choose.
• Override view all requests tab name: You may decide to re-name the View All Requests tab name. In the example below, we have re-named it "All Requests".

• Send single use authentication tokens on state transition: For API users only.
• Show custom form fields in emails to customers: Indicate whether you would like the fields from your custom forms to be included in emails sent to your customers.
• Custom pdf footer: Use the ext editor to add a custom footer to all pdf documents created from your core.
• Do not allow user to add additional services to a request? If you would like to allow users to add additional services to a request that has already been submitted, define this field as YES.
• Show request summary field? Define this field as YES if you would like to include a free text field to allow for a summary of the service request being submitted.
• Allow recurring charges on service requests?: Indicate that you would like to allow a service request to house a recurring service charge by defining this field as YES.
• Show workflow overview on new requests?: Indicate if you would like to display the workflow overview when opening new service requests. If defined as YES, the workflow will display as follows.
• Block core members from completing service requests? If defined as YES, core members will NOT be allowed to complete service requests.
• Auto-finish milestones? If you would like milestones to be automatically completed when a service request is complete, define this field as YES.
• Show billing and shipping information in the new request? Indicate if you would like to display billing and shipping information to the user when opening a new request. If defined as YES, the billing and shipping information will display in the COST section when opening a new service request and will have the ability to be edited.

• Custom text for billing and shipping information on a new request: You may use the text editor to add any text or images to display along with the billing and shipping information. In the example above, this space is used to ask the customer to review the information for accuracy.
• Which search scope should be selected by default when searching for a person to create a new request or reservation for?: Indicate what the default search parameters should be for the service request submitter. In the example below, the default is defined as ALL.

• Update service purchase date to completed date: Define this field as YES if you would like the purchase date (date the charge was added in iLab) to be changed to the completed date once the request has been completed.

Advanced

Advanced settings in the Service Request sub-tab can only be changed by iLab associates.

• Allow users to edit the Service ID/request name? If defined as YES, user will be able to change the service request ID by going into the EDIT screen.
• Allow selected services and requests to require core admin approval? Define as YES if you wish to be able to require admin approval for specific services and requests.
• Designated service and request approver: You may designate a single core member to approve all service requests if you wish by entering a name here.
• Set the color for collaborative projects: You should define a unique color for your core with which to display collaborative projects within the view all requests tab if utilizing collaborative cores.