design doc for reference

7/28/2019 Design Doc for Reference

http://slidepdf.com/reader/full/design-doc-for-reference 1/18

DESIGN Design Specification for Custom Sales Realignment App

Project Name:

Sales Realignment Application Project

Prepared for:

CLIENT

Document Owner:

Prateek Singh

Project Lead

Published: Feb. 28, 2012



Table of Contents 1. Scope Overview ............................................................................................................................. .............................. 4

1.1 High-Level Objectives............................................................................................................................. .............................. 4

1.2 Customer Requirements ............................................................................................................................. ........................... 4

1.3 Present Mode of Operation (PMO)....................................................................................................................................... . 5

1.4 Team Members ............................................................................................................................. ......................................... 5

2. Solution Overview ............................................................................................................................. .......................... 6 2.1 Naming Conventions ............................................................................................................................................................. 6

2.2 Data Model / ERD ................................................................................................................................................................. 6

3. PART 1: Assignment Rules Engine .......................................................................................................................... . 7 3.1 Overview ............................................................................................................................. .................................................. 7

3.2 Use Case Definitions Table for Assignment Rules ............................................................................................................... . 7

3.2.1 Use Case Process Flow for Assignment Rules .............................................................................................................. 8

3.3 Object & Field Definitions .................................................................................................................................................... 8

3.3.1 Assignment Rules Object ............................................................................................................................. ................. 8

3.3.2 Assignment Rule User Junction Object ........................................................................................................................ . 8

3.3.3 Additional fields on Lead Object.............................................................................................................................. ..... 9

3.3.4 Additional fields on Vertical Object ............................................................................................................................. . 9

3.3.5 Additional fields on Opportunity Object ...................................................................................................................... . 9

3.4 Apex Definitions ................................................................................................................. ................................................ 10

3.5 Page Layouts ....................................................................................................................................................................... 11

3.5.1 Page 1 .......................................................................................................................................................................... 11

3.5.2 .......................................................................................................................................................................... 12

3.6 Assumptions ............................................................................................................................. ...................................... 12

4. PART 2: Mass Re-Alignment Tool ......................................................................................................................... . 13 4.1 Use Case Definitions ............................................................................................................................. .............................. 13

4.2 Object & Field Definitions .................................................................................................................................................. 13

4.3 Automation & Business Logic............................................................................................................................................. 13

4.4 Apex Definitions ................................................................................................................................................................. 13

4.5 Visualforce Page Wireframes ............................................................................................................................. ................. 14

4.5.1 Page 1 – List view Page......................................................................................................................................... ...... 14

4.5.2 Page 2 – Mass Realignment Page ............................................................................................................................. ... 15

4.5.3 Functionality............................................................................................................................................................... . 15

5. Analytics ........................................................................................................................ . Error! Bookmark not defined.5.1 Custom Report..................................................................................................................... . Error! Bookmark not defined.

6. Project Risks............................................................................................................................. ................................. 16 6.1 Risks Identified by Client ............................................................................................................................. ....................... 16

6.2 Risks Identified by BrainSoft ............................................................................................................................. ....... 16

7. Exclusions ............................................................................................................................. ..................................... 17 7.1 View Assignment Rules ............................................................................................................................. ......................... 17

7.2 Fixing Existing Code / Test Coverage ............................................................................................................................. .... 17

7.3 Support for Other Objects............................................................................................................................. ....................... 17

7.4 Custom Lookups................................................................................................................................................................. . 17

8.0 Change Order Deifinition............................................................................................................................. .......... 17



The purpose of this design specification is to fully define the solution which BrainSoft, Inc. (“BrainSoft ”)

proposes to accommodate Client's requirements.

CHANGE HISTORY

DATE AUTHOR CHANGE NOTES 02-01-12 Prateek Singh Authored the first draft. 02-17-12 Prateek Singh Clarified requirements, challenged design, and made

updates. 02-19-12 Rahul Sharma Consulted with client on requirement clarity, new

requirements, and design considerations. 02-25-12 Rahul Sharma Committed updates to this design specification. 02-27-12 Prateek Singh Made final edits.



1. Scope Overview

1.1 High-Level Objectives

Client needs a faster, easier and more user-friendly way to mass assign Owners (and update key User lookupfields) across key objects all at once. To grow as a company and increase their clientele, reps need to save

time and frustration when manually making these updates in Excel. The following document will review

Customer Requirements, Present Mode of Operation, Data Model, Assignment Rule Engine and Mass Sales

realignment tool.

BrainSoft will design, build and deploy the following plan within Client's salesforce instance.

1.2 Customer Requirements

Our objective is to create an integrated Mass Sales Realignment Application within Salesforce platform, to

provide Client's administrators more easy and accurate ways of mass assigning record owners. We will follow

a step by step approach by reviewing the customer requirements to identify key areas to focus and review thecustomization of Salesforce to include any additional requirements for future enhancements.

Client uses Salesforce to manage their clients and prospects.

To assist Client with managing its records within Salesforce, BrainSoft will develop an assignment rules and

mass sales realignment application. Using this application Client will be able to manage all rules that

affect the assignment.

The customer's requirements include:

1. Build a tool for the sales team to more efficiently manage Ownership Assignment across leads,

contacts & verticals in one tool.

2. Contact owner will not be assigned directly instead they will be assigned via Verticals. If vertical

owner is changed all the associated contacts will be updated.3. The solution will stamp the Rule Criteria and Rule Name onto the Opportunity on "Closed Won" or

"Closed Lost". Rule Criteria Stamp should not be modified.

4. The solution will include a results page, giving the user the opportunity to not commit the changes.

This page is only required to hold the Object (Vertical or Lead) and number of records currently in

the system that meet the criteria as well as number of records (that meet the criteria) under Catch

All.

5. The solution will allow users at Client to manage the rules for assignment, based on internal changes

in Assignment Rules and Users in each Assignment Rule.

6. The solution will be coded specifically to handle one-off Assignment Rule Assignment situations, such

as when Queue is added then this rule will be applicable only to Leads not to Verticals

7. Ownership will be assigned as follows:

o Accounts will not be re-assigned with this project, as they are all assigned to Finance and will

remain so.o Leads owners may be assigned with rules and re-aligned with mass tool.

o Vertical owners may be assigned with rules and re-aligned with mass tool. 8. Another set of rules just for verticals will be created for updating user lookup fields. (In this

implementation we will support only Tenant ACH Rep and VAS Sales Rep fields). This requirement is

now out of scope.



1.3 Present Mode of Operation (PMO)

Client manually reassigns Leads, Accounts, and Contacts. Pain points are marked in red to stand out.

Excel Manipulation – The designed solution will make transferring records and managing Assignment Rules

easier without the added work of Excel manipulation. Now, Updating records will be completed within a fewclicks.

Assignment Rule Management – The designed solution will make managing Assignment Rules much

simpler and easier to use and adopt. Assignment Rules will be created as an object where the rules and

criteria will be managed for Leads and Verticals. We will leverage this application such an extent so that if

Appfolio wants to change any Assignment Rule, it is as simple as changing record within Salesforce itself.

Transferring Records – The designed solution will also make transferring records much easier to complete

as well. Currently, the users have to manage the Excel files. It can take many days to update the files before

using the Data Loader to update the records in Salesforce. With the designed solution users will be able to

transfer records to owners in Assignment Rules within a few short steps.



2. Solution Overview

2.1 Naming Conventions

•

Every time in the document if I refer to tool it is specifically Mass Reassignment only not referringAssignment RuleEngine

• Every time in the document if I refer to Application it implies both Mass Reassignment and

Assignment RuleEngine

• The words Re-alignment and Re-assignment are synonymous and used through-out this document to

mean the same thing. Essentially at a macro level re-align means the entire sales team will get re-

aligned when all records owners get updated, and on a micro level re-assign means the record is going

to get re-assigned to a new owner.

2.2 Data Model / ERD

This is the proposed data model for this project.



3. PART 1: Assignment Rules Engine

This section of design proposed by BrainSoft for Assignment Rule Engine, which includes use case

definitions, process flow diagrams, Visualforce UI mockups and apex definitions.

3.1 Overview

These rules will be used to when Lead or Vertical is created or when Lead or Vertical is updated as part of

new mass realignment.

Ownership will be assigned as follows:

• Accounts will not be re-assigned with this project, as they are all assigned to Finance and will remain

so.

• Leads owners will be assigned based on the assignment rules. If the Lead does not meet any of the

rules, it will qualify for the Catch All Rule and be assigned as the Catch All Rule dictates then record

will is assigned User denoted on the Rule.

• Vertical owners may be assigned/ re-assigned based on assignment rules. Vertical owners will not be

reassigned if the Vertical record is part of exception list.

3.2 Use Case Definitions Table for Assignment Rules

All use case definitions have been defined in this table. These use cases will be used as test cases to QA the

solution.

# Name Description 1 Create Assignment Rule w/

Multiple Users (Round-

Robin)

Create a rule, define the rule, and activate the rule.

2 Create Assignment Rule w/

Single User Create a rule, define the rule, and activate the rule.

3 Create Assignment Rule w/

Queue Create a rule, define the rule, and activate the rule.

6 Edit Existing Assignment

Rule Editing an existing rule, re-define the rule, activate the updated rule.

7 Inactivate Existing

Assignment Rule 8 Delete Existing Assignment

Rule There will be a validation in place where users CANNOT delete an Active

Assignment Rule. 9 Create/Edit/Inactive/Delete

a Catch All Rule



3.2.1 Use Case Process Flow for Assignment Rules

*See full image attached.

3.3 Object & Field Definitions

3.3.1 Assignment Rules Object

This object will define the Assignment Rules for both Leads and Verticals. This object will have 1 Page layout

and one record type (none). Hidden fields will be added accordingly to determine whether rule is for Leads or

Verticals or both. Trigger will update hidden fields on Appointment Rule object. Proper validation will be

added for special scenarios like junction object cannot be added when Rule Assigned to Queue check box is

checked.

Field Name Field Type Description Assignment Rule Name Text (80)

Lead Score (Min) Number Lead Score (Max) Number

Products Picklist (Secure Docs, Property Manager)

Units Managed (Min) Number Units Managed (Max) Number

Type Picklist (Leads, Verticals, Both) This will be a hidden field that

need to be populated by code Order Number Active Checkbox

Area Code Text Area (32,000) Rule Assigned to Queue Checkbox

Assignment Rule Description Text Area Long (32,000) Include Null Values (lead score) Checkbox

Include Zeroes (lead Score) Checkbox Queue Picklist

Include Null Values (units

managed) Checkbox

Include Zeroes (units managed) Checkbox

3.3.2 Assignment Rule User Junction Object

Field Name Field Type Description User Lookup (User)



Assignment Rule Master-Detail (Assignment Rule) User Role Formula Active Checkbox

Next in Line for Assignment Checkbox Only one of the users can be

true for each Assignment Rule Rule User ID Number

3.3.3 Additional fields on Lead Object

Field Name Field Type Description Reassignment checkbox This is used to check whether lead

assignment is required or not when

user update record. This will help

system to stop recursive action Assignment Rule Lookup (Assignment Rule)

Temp. Assignment Rule Lookup (Assignment Rule) This field will be updated during test

mass assignment isTestAssignment Checkbox This field is used to determin whether

this is a test or actual run by massalignment tool

3.3.4 Additional fields on Vertical Object

Field Name Field Type Description Reassignment checkbox This is used to check whether

lead assignment is required or

not when user update record.

This will help system to stop

recursive action Assignment Rule Lookup (Assignment Rule)

Temp. Assignment Rule Lookup (Assignment Rule) This field will be updated

during test mass assignment isTestAssignment Checkbox

3.3.5 Additional fields on Opportunity Object

Field Name Field Type Description Assignment Rule Lookup (Assignment Rule)



3.4 Apex Definitions

The following Apex triggers, classes, and controllers will be created for this project.

# Name Description 1 Assignment Rules

Trigger #1 -

ROUND-ROBIN

FOR LEADS

Scenario 1 : Whenever a new lead comes from Marketo (Round Robin

Trigger on Lead)

After Insert

Step 1: Check for the appropriate Assignment Rule Definition

Step 2: List all the “Assigned User” Records order by rule userId and assigned to

Assignment Rule definition in step 1

Step 3: If no records are found from step 2 make Catch all as the owner of the

record else Search for the user for whom "Next in Line for Assignment " is true

based on sequence of records from step 2

Step 4: Make this user as owner of the Lead Record and update Next in Line for

Assignment to False and update next record’s based on sequence for Update Next

in Line for Assignment to True.

Step 5: Also update Assignment Rule look up field with appropriate rule

Step 6: update Lead and Assigned User records.

Scenario 2 : Mass Realignment of Users using Assignment Tool (Round

Robin Trigger on Lead)

Create a Field on Lead object ( Reassignment-- this need to be check box

from code of Mass Assignment Page)

before Update

Step 1: Check if Reassignment field is checked and isTestAssignment is false

If step 1 is true follow step 2 and step 3 else check step 4

Step 2: If Step 1 is true then follow steps 1 - 5 of Scenario 1

Step 3: update Lead Reassignment field from checked to unchecked.

Step 4: if isTestAssignment is true update Temp. Assignment Rule field. Owner

field will not be updated. (Whole purpose of this field is to know how many rules

will be going to Catch All Rule before modifying the owner of the record)

2 Assignment Rule

Trigger #2 -

ROUND-ROBIN

FOR VERTICALS &

CONTACTS

Scenario 3 : Whenever a new vertical is created (Round Robin Trigger on

Vertical)

before Insert



Step 1: Check for the appropriate Assignment Rule Definition.

Step 2: List all the Assigned Rep records order by “Next in Line for Assignment” is

true

Step 3: If no records are found from step 2 make Catch all as the owner of the

record else assign the user as owner of the record and update the “Next in Line forAssignment” field (Proper care will be taken for how many SOQL and DML

Statements executed)

Step 4: Also update Assignment Rule look up field with appropriate rule

Scenario 4 : Mass Realignment of Users using Assignment Tool (Round

Robin Trigger on Vertical)

Create a Field on Vertical object (Reassignment-- this need to be check box

from code of Mass Assignment Page)

before update

Step 1: Check if Reassignment field is checked and isTestAssignment is false

Step 2: If Step 1 is true then follow steps 1 - 4 of Scenario 3

Step 3: update Reassignment field from checked to unchecked.

If step 1 is false and isTestAssignment is true follow step 4

Step 4: if isTestAssignment is true update Temp. Assignment Rule. Owner will not be updated.

after update

Step 1: Select all Contacts that are associated with the Vertical and update theowner Id to Vertical ownerId and update Assignment Rule field on Opportunities

that are closed and are associated with this Vertical. (Proper care will be taken for

how many SOQL and DML Statements executed).

3 Validation Rule Based on auto populated field custom validation will be placed so that user cannot

create special for both type of objects. For example if “Rule Assigned to queue” or

“Rule Assigned to User fields” is checked, then junction object cannot be added. 4 Trigger on

Assignment Rule

object

This trigger will be used to auto populate fields based on the criteria entered in

the Associated record.

3.5 Page Layouts The following Pages will be created for this project, just using standard page layouts and 2 custom objects.

3.5.1 Page 1

Assignment Rule page for Leads and Verticals:



3.5.2 Page 2

This is the Assignment Rule Users page:

3.6 Assumptions

• Assumes 1 page layout for the Assignment Rules object.

• Assumes 1 page layout for the junction object.

• Assumes no roll-back functions.

• Assumes contacts are assigned based on the vertical.

• Assumes sharing model will be supported, but manual shares will not follow re-assignment.



4. PART 2: Mass Re-Alignment Tool This section of design proposed by BrainSoft for Mass Re-alignment tool, which includes use case

definitions, Visualforce UI mockups and apex definitions.

The "Mass Re-Alignment Tool", will be used to push existing records in Salesforce through Assignment Rules.

Mass Realignment tool will be a custom visualforce page with apex code that will show data on real time.There will be one custom setting that stores status and count of the batch processes.

4.1 Use Case Definitions

All use case definitions have been defined in this table. These use cases will be used as test cases to QA the

solution.

# Name Description 1 Re-Align All Leads

and Verticals All the leads and verticals will be reassigned to new owners according to the new

rules defined or edited. 2 Re-Align Some

Verticals All assignment rules need to check “Hold” field on Vertical records and run rules

only against records for which “Hold” is false. This feature is only applicable forVerticals only. Hold field is already available in Vertical object.

3 Review Records -

Before Commit User needs to have the potential to view how many records will be entering into

catch all scenario before doing actual reassignment.

4 View Rule Criteria

on Opportunity The solution will stamp the Rule Criteria onto the Opportunity on "Closed Won"

or "Closed Lost", so we can report on this later. Trigger on Vertical object will

update Rule Criteria on all associated opportunities and field history tracking will

be enabled for this field. 5 Mass-Re-Align

Round Robin Test that if more than one user is associated with a Territory/Assignment Rule,

then the records get round-robin to the users. 6 Email Message An email will be sent to end user who has initiated the process once the job is

completed.

4.2 Object & Field Definitions

There are no additional objects or fields required for PART 2.

4.3 Automation & Business Logic

• Rule Criteria will need to be stamped on the Opportunity on “Closed Won” or “Closed Lost” so that

reports can be used to track this.

• Once the records have finished transferring, the current logged in user will receive an email with the

status of job.



4.4 Apex Definitions

The following Apex triggers, classes, and controllers will be created for this project.

# Name Description

Mass Realignment

Controller This class will be used as event handler based on the user action (in this case

which ever button is clicked) different jobs are fired

2 TestReassignBatch This is a batch that executes when user clicks on test reassignment. This job

will not update the owner of the record instead they will update isTest

checkbox checked. Remaining part need to be handled by Triggers on Leads

and Vertical object. All this object does is gathering the list of records to

process. List of records that gathered for reassigning vertical should include

records which on Hold. 3 ActualReassignBatch This is the actual Batch job that will update the owner records. All the work

must be taken care by triggers itself. Batch apex will help to fetch the records

and make sure we are well inside all governor limits. Reduce the batch size if

we are trying to hit or over 70% of any governor limit. 4 Email Message This is an email routine that sends the email once each batch is completed.

4.5 Visualforce Page Wireframes

The following Visualforce pages construct the Mass realignment tool which will be created for this project.

4.5.1 Page 1 – List view Page

Click on “Reassign Leads and Verticals” button on the list view page



4.5.2 Page 2 – Mass Realignment Page

4.5.3 Functionality

Note:- Please don’t use Final Reassignment and Reassign User field’s button concurrently. This may leads to lock

condition. Reassignment of Owners and Reassignment of User fields need to be done one after another.

Title Functionality Test Reassignment

Button • This is a trail run and none of the record owners are updated at this

point.

• This process might take less time to complete compared to actual batch

process that changes the owner records as none of the owners will be

updated in trail run.

• When we click on this button a batch job will be started and once job is

completed salesforce will send an email stating “Test Reassignment” is

completed.• Finally users can see how many records will under catch all scenarios.

Final Reassignment

Button • Record Owners will be updated and updates the Assignment Rule on

both Lead and Vertical records.

• When we click on this button different batch job will be started and

invokes Assignment rules using trigger on Lead and Vertical object.

• Once batch job is completed salesforce will send an email stating “Final

Reassignment t is completed”.

• Reassignment will update only owners of leads and Verticals. None of

the user fields on Verticals will be updated during this phase.



5. Project Risks

5.1 Risks Identified by Client

• We have some 3rd party apps that are not meeting Test Coverage.o 9 custom objects o 338 test classes o 31 triggers o 58 rules o Used .54% of our 3MB character limit.

• There are some other apps that are making changes in the org, but we won't need to interact with

them.

• There is nothing that I know of that is triggering off of the Owner field, so shouldn't be any problems

here. I'm loading in Data Loader in mass, and have not seen any adverse side effects.

• Org is set to private. We are heavy users of Sharing Rules (Criteria Based Sharing), we share based on

record-types, etc...

• There is only one instance where we have a manual share in place.

• We are also granting access using hierarchies / roles.

o Leads are Public/Read/Write o Accounts private o Contacts private o Activities controlled by the parent

5.2 Risks Identified by BrainSoft

The following would be at risk if a single mass-update exceeded 1,000,000 records:

• Total number of executed code statements for Batch Apex and future methods

• Total heap size for Batch Apex and future methods

• Total number of SOQL queries issued for Batch Apex and future methods

• Total number of DML statements issued

• Total number of records retrieved by SOQL queries. There might be performance degradation as data

volume grows in millions.

• Proper block out period need to be given by testing the reassignment in Sandbox before reassigning

in production.

• Total number of methods with the future annotation allowed per Apex invocation. For most of the

part we should be good but in future we may consider this as the data volume grows in millions.

• Record Locking is another known scenario that might occur. For example if system updates certain

lead record and at the same time if some rep works on that record locking might occur.

• Account Data Skew is one more issue that needs to be considered as all the accounts are associated to

specific users.

• Occasionally there might be a “Batch Apex Time outs” due to high volume of data.

• Overall time to complete the process will be more than anticipated as the sharing model is private.

For example if we change owner of Contact record not only contact record is updated but also all its

corresponding records like sharing rules with respect to the contact record. Even activities will be updated to the new user.



6. Exclusions This is a partial list of known items that are out-of-scope.

6.1 View Assignment Rules

No list views or reports will be created for assignment rules object except view all that comes by default.

6.2 Fixing Existing Code / Test Coverage

Any existing code or test coverage that needs to be updated in order to deploy, will require a change order.

6.3 Support for Other Objects

The scope of this project is limited to the Lead, Contact, and Verticals Objects.

6.4 Custom Lookups

Any new Custom User Lookups that will need to be updated on Verticals is out of scope at this time.

7.0 Change Order Definition

Original Assumptions:

3.1 Standard Assumptions

Change of Scope: It is assumed that the scope of the work outlined herein will not change. However, should

the scope of the work change, and additional resources or levels of efforts be required or additional system

functions, business processes, source systems get identified during the project, then such changes mayincrease the overall project cost and/or timeline. Such changes will be addressed through the use of

BrainSoft's Change Request Form. BrainSoft will work closely with Company’s project team and management

to identify the impact to the overall cost and time of the project.

BrainSoft will offer the following solutions.

1) Comprehensive design specification estimated at up to 50 pages to accurately define the

specifications, data model, fields, API calls, visualforce pages, apex, etc...

2) BrainSoft will build a tool for the sales operations team to more efficiently manage Territory

Ownership Assignments across Leads, Contacts, & Verticals in one tool.

3) BrainSoft will build a Mass Re-Assignment tool for the sales operations team to use a custom report

to define criteria for mass re-assignment across virtually any object, field, etc...

4) The solution will stamp the Rule Criteria onto the Opportunity on "Closed Won" or "Closed Lost", so

we can report on this later.

5) The solution will include a results page, giving the user the opportunity to not commit the changes.

6) BrainSoft will host User Acceptance Testing and deploy the solution.

7) BrainSoft will create custom Courseware to document how to use the tools.

8) BrainSoft will train the team on how to use the tools

Assumptions from Statement of Work (Items that have changed are highlighted)

-Assumes 1 custom Territory Object, and 1 custom Junction Object which will associate the Users with the

Territory.



-Assumes 1 Territory Definition (the last to be executed) will be the "Catch All" territory, which can be a User

or a Queue.

-Assumes 1 page layout for the territory definition.

-Assumes 1 page layout for the junction object.

-Assumes no roll-back functions.

-Assumes no formula based-criteria.

-Assumes the solution will only support the following 7 criteria: Rep ID, Area Codes, Vertical/Product Type,Rep Type, Territory Name, Account Team, Lead Score

-Assumes contacts are assigned based on the vertical.

-Assumes the solution will include the following operators: Equals & Not-Equal-To

-Assumes solution supports assignment to users, not queues

-Assumes sharing model will be supported, but manual shares will not follow re-assignment.

-Assumes the logic of this core requirement will be defined in the Design Phase, broken into individual

deliverables, which may shrink or grow the Hours Estimate.

-Assumes 2 triggers on Leads & Verticals (since contacts follow Vertical Owners).

-2 Visualforce Pages

PAGE 1-Criteria will be based on a custom report.

PAGE 2-Sample records will be displayed with a total count, based on the criteria from the custom report.

(Refer to Conga)

-Button that says "Transfers" or "Re-Assign".-EMAIL UPON SUCCESS -An email will be sent to the current logged in user upon success, which will include #

of success and # of fail.

(Simply run a custom report for "Catch All" to view the failed records).

-Assumes re-assignment / transfer will be a batch job.

-We need to stamp the Rule Criteria onto the Opportunity on "Closed Won" or "Closed Lost", so we can report

on this later.

-PAGE 1 & 2:

-Display List of Custom Reports

-Pull Criteria from Custom Report

-Display List of Results & Sample Records (20 per page)

-Display Total # of Records

-Pagination of Results

-Assumes user will create a Custom Report to define the criteria & filters, by which this tool will reference.-Assumes custom report will be stored in 1 specific report folder (like Conga).

-Round Robin Procedure

-Success Email

-Assumes up to 3 rounds of revisions. Additional time will require a Change Order.

-BrainSoft will provide client to log and track progress of all bugs/defects, and will support all bugs that

are related to the scope of effort defined, that are logged within 30 days of BUILD completion.

-Assumes testing in a full sandbox of 15 use cases, up to 3 rounds of testing.

design doc for reference

Documents