Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Salesforce Package

What is a Salesforce Package?

Salesforce packages are like Add-ins for Microsoft Word. For example, you start with the base product, Microsoft Word, and then you add a spell-checker program such as Grammarly or ProWritingAid. The Add-in can be upgraded on its own, without affecting the base product. It adds functionality and integrates with the base program. In Salesforce, packages are introduced to the base product, which is the Salesforce org, to add functionality, such as payment processing. Salesforce packages can also be upgraded, like Microsoft Word Add-ins, without disturbing the base product. Or vice versa, the base platform can be upgraded without necessarily disturbing the package. Packages are the bases for all Posimente products. Posimente creates, develops and maintains packages.

How Packages Are Used To Build Products

PosiEd is a suite of apps built for Schools and other educational institutions. It is actually a suite of applications designed to provide a degree of granularity and choice for each client as to what areas of functionality they wish to implement.  

The packages behind the overall PosiEd solution that are built and maintained by Posimente include.  

  • PosiEd  

  • PosiEd K to 12 

  • PosiEd Well-being 

  • PosiPay 

  • PosiPay Fundraising 

Posimente develops and maintains these packages with the goal of continuously improving security and keeping them in line with advancements made by Salesforce on their platform.  

Org Types

Salesforce has a system intended-use structure similar to what you find for servers in standard IT infrastructure, which typically looks like this: 

  1. Production 

  2. Non-production 

Or this: 

  1. Production (PROD) 

  1. User Acceptance Testing (UAT) 

  1. Development (DEV) 

The Salesforce hierarchy of orgs looks like this: 

  1. Production (Live) 

  1. Sandbox (Testing) 

  1. Validation (Packaging) 

  1. Scratch (Development/Design) 

Other than production, the only other org your administrators will touch will be the sandbox, which will be used, for instance, to conduct change management and testing. Validation and scratch orgs are only used by developers to create and package products. This leaves the production org as the main org for most users. 

 Customised Installation

In the context of Salesforce orgs, the term “customised” refers to any changes to the configuration of the system which occur outside the Salesforce package used to build your system. We are not referring to the addition or deletion of data, but to configuration and setup changes performed after the installation, to enable requirements not found in the package.

The rule of thumb is that the fewer customisations you can get away with, the better, because of the implications for what happens when you upgrade, install new packages, or introducing other standard functionality. It is possible that you won't be able to upgrade using the standard process, or that the customisations you have added will be permanently lost. Please read Upgrades for more details about the upgrade process. 

Upgrades

Your installation will require two ongoing tiers of installation requirements: 

  1. Salesforce platform upgrades 

  1. Posimente package upgrades 

Salesforce has its own upgrade pathway, which you have little to no control over. For instance, when they are ready to make a major platform change, like Spring or Summer 22, they make announcements, and it is your responsibility to prepare for the upgrade. Your organisation may need to do nothing, or you may need to ensure the upgrade doesn't adversely affect your data because you didn't prepare properly. Remember, because the Salesforce platform is cloud-based, when they decide to push out new code across their platform, it affects everybody, everywhere in the entire world! It might sound a little scary, but it's not really. Not if you are prepared. 

Posimente also has its own upgrade pathway, for the packages it develops and maintains. This is split into two sub-paths: 

  1. Changes to packages in response to upgrades planned by Salesforce 

  1. Upgrades to packages to increase performance, add features, deprecate features, or improve security 

Posimente keeps a finger on the pulse of Salesforce. We keep abreast of code changes to their various platforms, and respond as needed with upgrades and changes to the packages you use in your org. 

Upgrades to your org must be planned. Please work with us to make sure you have no service interruptions. It's your responsibility too to make sure the viable window for upgrades doesn't expire, meaning if you wait too long it's going to be extra difficult and cost you more than if you had kept up with the upgrade path we maintain. If some cases, if an upgrade is put off too long, it is no longer possible to perform it using the standard process, and it then becomes time-consuming and expensive. 

For the best results, keep in touch with us! 

 Salesforce App Exchange

Background 

Salesforce App Exchange is a marketplace where organisations shop for apps to use in their Salesforce orgs. Each app has a listing which describes the functionality of the app, shows examples of use, presents a brief introduction, and includes technical information such as requirements for setup and package versions. Salesforce puts each vendor app for sale or subscription through a rigorous security check before it fully endorses it as an approved App Exchange app. 

Posimente App Listings 

Posimente currently has two security-checked and approved apps listed on the Salesforce App Exchange: 

  1. Posi Wellbeing 

  1. ProntoPayments 

The PosiEd app will be submitted for security review prior to end of 2023.

  • No labels