Skip to main content

​
fusionCore Overview

​
Overview

fusionCore is a series of packages built on top of Salesforce, these packages were designed to allow mission-based organizations to leverage opportunities/products for their day-day needs. At the minimum, it contains the following:
  1. Subscriptions
  2. Community Store
  3. Stripe Integration

​
Why use fusionCore?

  • fusionCore leverages a large amount of base salesforce functionality.

​
What are the packages in fusionCore?

fusionCore consists of a variety of managed packages. The following 2 are required in order for the system to work
  • Platform
  • Commerce
The remaining managed packages are typically installed as well:
  • Stripe
  • Subscription
  • Portal
In addition to these managed packages there are a few recommended unmanaged packages that should also be installed:
  • Layouts

​
What is the cost of fusionCore?

Contact the fusionSpan sales team for pricing of fusionCore.

​
Frequently Asked Questions

​
Who is responsible for maintaining the fusionCore (bugs and new features)?

  • The fusionCore team is a dedicated team within fusionSpan. Please send a ticket into [email protected] with your question.
  • This package is fairly new

​
Are there any resources around current fusionCore functionality?

  • LMS course and implementation guides TBD

​
Will fusionSPAN be providing updates for fusionCore?

  • fusionCore is a fairly new package. Initially expect fairly frequent updates (Approx 1 per month). Long term, we plan to have updates once per quarter, with the exception of major bugs.

​
Where do I go for any fusionCore updates/announcements?

  • Please subscribe to the #fusioncore-announcements channel in slack!

​
How does one create a new feature or report an improvement to an existing feature?

​
How does one report a bug in fusionCore?

  • Please send your request to [email protected] with your request. Ensure you fill out the following details:

​
How do I request a demo org?

There are 2 types of demo orgs for fusionCore:
  1. Latest development build
  2. Sales Orgs

​
For the Latest Development build:

  1. In slack, in any channel type: /sforg
  2. On the form that appears, fill in the following
    1. Alias
      1. FSI-<random number>
    2. Org Type
      1. fusionCore
    3. fusionCore Version (NOTE this only appears with fusionCore is selected as the org type)
      1. Latest (or if you want a specific version, choose that)
    4. Scratch Org Namespace
      1. None ← Choose the option none do not leave it blank
    5. Timezone
      1. Choose whichever timezone is closest to you
    6. DX Config
      1. Leave blank
  3. Wait about 30 mins, you should receive a notification in slack once complete.
See this video for an example:

​
For Sales Orgs, you can do the following:

  1. If Sales Team needs a demo org. They should request it from the accelerator team via management.
  2. A new epic should be created in the Salesforce Accelerator Jira space with all the packages needed for that demo org as tasks.
  3. Requestor should be sent the Jira epic so they can track changes.
  4. Once completed, requestor should be notified.

​
Team Operations

​
Roles and Responsibilities

RoleNameResponsibilities
Shared ResponsibilitiesAll* Creating New Features * Maintaining existing features + Bugs - Determining whether or not something is a bug - Ticket management. Keep an eye out for new bugs in the backlog + New Releases + Enhancements * Updating Demo Org(s) for Sales Team
Product ManagerAssesses the market, the features defined for the product.
Scrum Master / Project Manager* Works with the Product Owner/Solution Architect on maintaining timeline * Leads backlog refinement * Leads retrospectives * Leads Daily Standups * Review sprint burn down and velocity reports * Ensure team members have enough tickets to work on * Remove blockers * Review backlog with the PO and tech leads * Helps the team with release grooming and planning
Product Owner / Solution Architect(Temporarily)* Takes requirements from Product manager * Creates simple prototypes using base salesforce * Write up initial requirements. * Creates epics * Determines impact to roadmap * Determines what release to introduce the feature. * Determines what executive showcase/release to place the feature in * Provides inputs to SM on the release planning
Technical Architect* Review and Provide feedback to the PO/SA on the intended solution + Noting any technical limitations + Noting any gaps in user stories/use cases * Coming up with technical design of the feature * Create Protoypes of feature * Documentation support + Reviewing user stories + Assisting with scenario creation + Create Input Conditions and Expected Outcomes + Ensuring that Technical Details are filled out as needed * Breaking down solution into Jira tasks on the Epics created by the Product Owner * Code Reviews * Packaging + Ensure the package install links are up to date on the document
QA/SDET* Test Plan Creation + Oversee test plan creation in browser stack * Test Automation Creation + Create automated test cases * Run test plans and test the features/tickets
BA* Documentation of the features (new and existing) + Working with the SA and TA to generate user stories as needed + Other team members can support this task as needed * Doing BA QA of the features to ensure that the business use case is met + Other team members can support this task as needed + BA will confirm feature readiness from the business requirement POV * Assist the SA and TA with maintaining the backlog * Creating Prototypes * Creating Demos and leading demos * Creating end user guides
Developers* Code solutions based on Solution documentation * Assist with QA * Assist with filling out technical details on solution document * Own a particular feature (epic) + IE be able to know why we built it, how it works, and be able to recommend any pain points/functionality that we should add - NOTE: This person does not need to code everything on the feature, just be aware of it.

​
Feature Design Considerations

When developing new features ensure that you keep the following rules in mind:
  1. Keep it simple
    • Avoid using excessive fields or processes to solve your problem. When you design a system. Take a second to ensure there isn’t a simpler way to meet your needs
  2. Avoid excessive configuration steps
    • Your solution should be quick to configure. Determine what features currently exists. Can you leverage these features to minimize configuration?
    • For Developers: Do I really need another custom metadata setting? Can I leverage whats there already to achieve my solution?
  3. Prototype it
    • Create a very limited functionality of the prototype. Walk through how it would look to setup, configure and what data would change as your solution runs.

​
Feature Design to Package Process

The steps listed below go over how we take a feature from idea to final product

​
Step 1: Ideation

  1. Feature request comes in from an external Stakeholder to the Product Manager
  2. Product Manager works with Stakeholder to fully validate the request
  3. Product Manager creates/expands on the content in the feature request epic.
  4. Product Manager and Product Owner meet for knowledge transfer and to better flesh out the functionality of the feature request
  5. Product Owner expands the epic as needed and creates any supporting documentation.

​
Step 2: Planning and Work Breakdown

  1. Feature request comes in from Product Manager or Product Owner
  2. The Product Owner works with the Product Manager to determine priority.
  3. Product Owner reviews and creates epic
  4. If the feature is complex:
    1. Product Owner creates an enabler under the epic to and works with Technical Architect or Business Analysts
  5. Product Owner (or Technical Architect if dev heavy) fills out epic with problem, intended solution, examples and any other resources that are useful for the team
  6. Product Owner creates as many follow up tasks as needed under the epic. The typical tasks needed are
    1. Create Mockups (if UI Component)
    2. Create Solution Document
    3. Create Test Plans
    4. Develop Solution
    5. Full QA
    6. Create/Update End User Guide
  7. The Technical Architect briefly reviews the Develop Solution task and splits it as needed into smaller tasks
  8. The Product Owner reviews the tickets and determines appropriate package and release (jira fix/versions) and adds the tasks tickets to that release
    1. NOTES:
      1. Epics are not tied to a release
      2. A task can be in up to 2 releases
        1. Product Version
        2. Stakeholder Showcase
  9. All tasks should meet the Expectations of a Jira ticket
  10. At this point we have a high level work breakdown that we can use for planning purposes. Not all the tasks might be fully there as more can be discovered during solutioning. This is fine, if something significant comes up during solutioning, we can re-assess as needed.
    1. Product Owner need to review the new tickets added

​
Step 3: Solutioning

  1. The Business Analyst creates a rough draft of the solution document
  2. The Technical Architect and QA Lead reviews this solution document
  3. The Business Analysts, Technical Architect and QA Lead all meet on the feature and finalize details on how it works.
  4. The Technical Architect completes the solution document
  5. The Technical Architect add/updates Jira tickets as needed based on intended solution
  6. The Lead QA creates test plans based on the solution document and requirement session
  7. Product Owner Reviews solution document to ensure it meets original design spec and reviews tickets created/modified as a result of the solutioning process to determine whether there is impact to the timeline.

​
Step 4: Development

  1. Tickets are assigned to team members (mainly developers) in the prior sprint
    1. These tickets are a combination of: Development, Solutioning, Test Automation, etc.
  2. Team members review their tickets and descriptions prior to sprint planning
  3. Tickets are reviewed during sprint planning and hours estimation are confirmed.
  4. Final ticket assignment/re-assignment is completed during sprint planning
  5. Tickets are picked up and go though the following stages
    1. Open → In Progress → BA QA → Code Review → Full QA → Done
      1. Open: Ticket is ready for work. Pick up the highest priority ticket first based on priority field and order of the tickets in your board. The closer to the top, the higher the priority.
      2. In Progress: Devs create a feature or bugfixbranch from the release branch under the associated repository and continue their work on that feature branch. Once the work is completed:
        1. A pull request is created
        2. A video showcasing functionality is uploaded to the tickets in JIRA
        3. Technical Documentation is added to the respective solution
      3. BA QA:
        1. The Business Analyst reviews the video and ensures that it meets the use case. This typically takes 15 mins. Tickets in this status are high priority.
      4. Code Review
        1. The Technical Architect reviews and moves the code to full qa.
        2. Tickets in this status are high priority.
        3. Can be done concurrently with BA QA
      5. Full QA
        1. If an epic has a separate full qa ticket that is not complete, this step is skipped
        2. Otherwise the QA team member carries out full qa checking
          1. Status of CI/CD
          2. Creating a test run in browserstack and ensuring that relevant tests are passing.
  6. All team members complete tickets no later than the 2nd Wednesday of the sprint. The remaining time should be used for fixing issues flagged in tickets and next sprint ticket prep.

​
Step 5: Internal Demo Prep

  1. The Business Analysts prepares a demo of the items completed in last sprint.
  2. The Business Analyst schedules time with the Product Manager and Product Owner to demo the feature. Ideally this should be immediately after Post DSU
  3. The Business Analyst takes feedback and creates follow up tickets to incorporate the changes as needed.

​
Step 6: Stakeholder Demo

  1. The Business Analysts creates a demo for stakeholders showcasing the features that were created after the last few demos. These features showcased should be listed in the respective showcase release.
  2. The Business Analyst takes feedback and creates follow up tickets to incorporate the changes as needed.

​
Step 7: Packaging

  1. Once all the tickets within a package release are completed, it is ready for packaging.
    1. The product owner creates a ticket for all the packages that should be packaged. This ticket should contain the following:
      1. T
      2. The package version of the beta packages that needs to be promoted to a release package
        1. NOTE: Beta packages are created every time a pull request is merged into a release branch
    2. The Technical Architect or someone with access to promote a package will convert the package into a release package.