This document serves as a checklist to gather all required information before configuring Cloud Maven’s Secure File Transport application. Collecting these details ensures the application is properly aligned with the client’s Salesforce processes, domain settings, automation needs, and compliance requirements.
Who should fill this out: Sections 1–2 are best answered together with your Salesforce admin and IT/email contact. Sections 3–8 are typically completed by your Salesforce admin, since they involve page layouts and automation. If you're not sure who owns a section, just leave it blank and flag it — we'll walk through it on the kickoff call.
Onboarding & Contacts
|
Question |
Response |
|---|---|
|
Primary implementation contact (name, email, role) |
|
|
Expected go-live date |
|
|
Target environment for initial setup |
|
Domain & Email Setup
|
Question |
Response |
|---|---|
|
Do you have an existing Botdoc account, or do you need one set up? |
|
|
What subdomain will be used to send out the file requests? (For example: securedocs.cloudmaveninc.com) |
|
|
Which version needs to be setup P1(Push or pull) or P2 (Container)? |
|
P1 Version:
P2 Version:
Source Object Details
|
Question |
Response |
|---|---|
|
Which is the Source Object on which File Request needs to be setup? |
|
|
Which record type(s) should have the File Request feature? In Salesforce, this is called the "Source Object" — e.g., Case, Opportunity, Patient Record, Contact. |
|
|
What fields should be used from the Source Object to get the Name, Email and Mobile# to auto populate the components? |
|
|
Which apps need the Request Files/Send Files button or Related List list visible? Example: "Service Console." |
|
|
Which page layouts/lightning pages need the Request File button or list visible? Example: "Case Detail page," "Service Console." |
|
|
Which specific screens need the Media File component? This component keeps a track of all the Files that have been uploaded by the customer. This is what Salesforce calls "Lightning Record Pages" — the layout a user sees when they open a record. |
|
Default Request Behavior
|
Question |
Response |
|---|---|
|
What should be the default mode to send the requests? Email or Phone or Both |
|
|
What should be the default Expiry Date? (Expiry Date: after this date the secure link to upload the files will expire.) |
|
|
When emails go out, what should recipients see as the "From" address? Choose: the logged-in user's own email, or a shared/generic address (recommended for support teams). If a shared address, please provide it. |
|
|
Do you want to enable Two factor authentication? If yes, the code should be received via Email or SMS? |
|
|
In case of P2 : How far back would you like to see requests in the Inbox? |
|
Email Templates
|
Question |
Response |
|---|---|
|
Please provide the verbiage of Email Templates that might be used to send out File Request for each object(s) The template includes the SMS Message (if enabled), Email Subject and Message, Portal Message displayed when the customer opens the secure link, and the File Tags available for selection. |
|
White Labelling
Access & Licensing
|
Question |
Response |
|---|---|
|
How many licenses do you need? |
|
|
Which users or profiles need access to Secure Email? |
|
Bulk/Automation Preferences
|
Question |
Response |
|---|---|
|
Should Secure Email be triggered automatically in certain situations? Examples:
If Yes → Please describe automation logic: |
|
|
Which template needs to be used for automation? |
|
|
Do you want to enable Bulk Secure Email functionality? If, yes we would need the mapping of the Object and the Email field which will be used to send the emails. |
|
Batch Frequency
Notifications
|
Question |
Response |
|---|---|
|
How should users be notified when a secure email comes in? Select all that apply: Salesforce notification (bell icon), email alert, or no notification needed. |
|
Thank you for completing this questionnaire. Please return it to your Cloud Maven implementation contact — we'll follow up to confirm details and schedule your kickoff call.