Deploying/Exporting solution containing table with lookup columns

[Farhanftp]

Can anyone suggest me a solution for this?

We are two teams working on two different solutions in an environment. 

The teams have individual tables of their own and one table in common. Both teams created lookup columns to this table from their individual tables.

I tried to export the solution by including all of the tables in my solution along with the one shared table, but it was showing dependency error because of the lookup column created by other team.

How can I include the shared table in my solution along with my team's table only and get no dependency errors?

Can you suggest a solution to solve this dependency issue?

[Velegandla · Accepted solution]

@Farhanftp 

You can reference the common table in both solutions  or one of the solution that is getting deployed first. This would make table available Target and next solution will get deployed without issues. 

As long as no one changing the common Table or communicate the changes then it should work as expected. 

====================================================

If I have answered your question, please mark your post as Solved.
If you like my response, please give it a Thumbs Up.

https://www.linkedin.com/in/devendravelegandla/ 

[SteRe · Accepted solution]

Just to mention another option, you could build a 3rd solution containing the shared table and deploy this first. This ensures to have shared objects present in target environment when team specific solutions get deployed. 

[Farhanftp]

@SteRe 

We could deploy the shared table into another solution.

But since the shared table has lookup columns, we need to include those tables as well. If I include the related tables, it will still show dependency issue because the related tables have lookup columns inside the. Altogether I will endup adding all tables inside one solution.

Any way to solve this?

[SteRe]

Generally, yes. 

In general, each table exists only once. The solutions contain references to the single object which allows to have a table been used in multiple solutions. Let me summarize what I understood

• Solution A - managed by dev team a
• Solution B - managed be dev team b
• Table 1 - shared
• Table 2 - dev team a
  • has references to table 1 as lookup to table 1
• Table 3 - dev team b
  • has references to table 1 as lookup to table 1

So when deploying both solutions there is a dependency issue named in case table 1 is not part of the solutions. This would be correct as table 1 must be in your target environment first or deployed within solution A or B to resolve this dependency solution internally. 

Are there any backlinks from table 1 to other tables? 

You wrote you've removed the relations from that table, have you also removed the corresponding fields from the solution as well? Are non of those removed fields used by forms and views?

[SteRe]

In one of the duplicated post you wrote

---

@Farhanftp wrote:

Target  environment is unmanaged. Table and solution will be managed in the production.

Sounds like you are running different dev systems, combine the changes at a build environment and create a manged solution there. Or why would your target environment be unmanged while production is managed?

[Farhanftp]

I have a total of 3 environments - all are unmanaged ( it was provisioned like this by the admin - I am planning to request to change the prod to managed) . One environment for hosting pipe line, one for dev and one for prod. 

Currently I am trying to deploy from dev to prod.

[SteRe]

Environments are basically unmanaged at all. Sure, there is a newer feature called "managed environments" but this is more then intended by "managed deployment". 

Bases on your latest post I understood you run your development at dev (unmanged), deploy several solutions to your build / hosting pipeline environment (unmanged) and from there you export managed to have this deployed to production then. 

I would always recommend having at least one (test) environment to which you deploy exactly that package you are going to use for production, so you can see if your deployment can work. 

But this is a different topic. 

How about my earlier post summarizing the setup with your tables and solutions?

[siforibo]

Hello, I have the same problem. Did you find a solution for this problem?

[Farhanftp]

Hi @siforibo,

Yes, I followed the below steps:

1. Created a solution for the shared table. I included all objects in the properties while adding the table into the solution. If you are creating shared table as new inside the solution, you will not be asked any properties.
2. Deployed the Shared solution into Production.
3. Created a new solution for Team A. Added the shared table. While adding I custom selected all objects by marking the columns, meta data and relationships. Didn't choose include all objects by default. 
4. Published the team A solution into production.
5. Created solution for Team B. Added the shared table. While adding, I avoided all the columns and relationships that are not a part of the original shared table.
6. Published Team B solution into production.

Make sure to publish the shared table solution into the Production first.

If this helped, please give me kudos👍