Apex Code Development You need to sign in to do that
Don't have an account?
Platform Integration: Has anyone heard of a commercial vendor asking to install multiple classes/VF pages manually into your org?
Hi all,
Hoping to get some community feedback here to help benchmark whether I'm being too paranoid.
Situation: A commerical SaaS platform vendor has pitched their platform to my company. They have stated that they have "Salesforce Integration" with their platform. All I have access to at this point is a 'configuration' document from them describing how to configure our org for integrating with them - create Connected App/SSO, custom domain and even manually create a custom setting with fields they specify in their doc. So far, so good.
Then, at the end of their 'configuration' document, they list 22 classes and 6 Visualforce pages for us to manually create via copying/pasting of source files into our org, that they will presumably provide us.
Am I unreasonable to think this seems crazy in terms of:
We've already inherited a complex org in terms of coding customizations and test coverage issues, so I might be particularly sensitive to adding additional code/complexity that we would have to take the time to review ourselves and support going forward.
Even if we ultimately agree that their source is a 'reference implemention' that we will enhance/extend, shouldn't they be providing it as an unmanged package at the very least?
Thanks for any perspectives and thoughts.
-L
Hoping to get some community feedback here to help benchmark whether I'm being too paranoid.
Situation: A commerical SaaS platform vendor has pitched their platform to my company. They have stated that they have "Salesforce Integration" with their platform. All I have access to at this point is a 'configuration' document from them describing how to configure our org for integrating with them - create Connected App/SSO, custom domain and even manually create a custom setting with fields they specify in their doc. So far, so good.
Then, at the end of their 'configuration' document, they list 22 classes and 6 Visualforce pages for us to manually create via copying/pasting of source files into our org, that they will presumably provide us.
Am I unreasonable to think this seems crazy in terms of:
- owning their test coverage and and any related test failures within our org (i.e., blocking production deployments, etc.)
- dealing with any current/future namespace conflict with their source file names
- just generally our 'owning' these assets as if we had developed them ourselves
We've already inherited a complex org in terms of coding customizations and test coverage issues, so I might be particularly sensitive to adding additional code/complexity that we would have to take the time to review ourselves and support going forward.
Even if we ultimately agree that their source is a 'reference implemention' that we will enhance/extend, shouldn't they be providing it as an unmanged package at the very least?
Thanks for any perspectives and thoughts.
-L
It shouldn't cause namespace errors (becasue being unpackaged - it has no namespace) and they *should* be in charge of the code coverage for those classes they provide.
Ideally yea you would get this in an unmanaged package (I would expect from the sounds of it they intend to make some tweaks and updates to the files to enable it to meet your exact needs hence why it is not managed).
You are not being overly cautious/sensitive just practicing good due diligence and governance (which is a VERY good thing). I would ask the vednor why they don't distribute it as a package and what they intend to change in it (if anything at all). But suffice to say you do not have to be too worried.